Open firebird-automations opened 13 years ago
Commented by: @hvlad
Classic is not affected as there is no other activity except of merge itself in the same page cache instance. I.e. there is no user process which could change page marked with BDB_merge flag. Note, this optimization not applicable for Classic.
Solution is to undo such optimization. Another way to avoid double writes could be implemented but not in this ticket.
What if just clear BDB_merge in CCH_MARK?
Hmm... looks like good idea
May I ask you to not restore old code as is - instead of add new argument into CCH_fetch_page()
(and all callers), consider CCH_mark_merge()
or something like it.
I thought about the same. I'll try to minimize changes.
Submitted by: @hvlad
When merge is in progress engine writes changes into both delta and main file. This creates additional IO load of course. Therefore in v2.5 merge process was optimized - when page is read from delta file for merging purposes it is marked (with BDB_merge flag) and not writed back into delta. It is OK if page not leave the cache until merge done. But there is a scenario when this optimization is wrong : a) page is read by merge process and marked by BDB_merge flag b) page is changed by some user attachment and written into database file only c) page is evicted from the page cache d) user attachment going to change that page again e) page is read from delta, this copy have no changes by (b) ! f) page is changed and written into both database and delta, overwriting changes by (b) in database
Commits: FirebirdSQL/firebird@4a916be1a3302dcf48f7b7f93e0bc75c5dc6bf80 FirebirdSQL/firebird@d57814996f5caf52d44d09e077846b39cf658e5d