Обсуждение: Why is get_actual_variable_range()'s use of SnapshotNonVacuumablesafe during recovery?
Why is get_actual_variable_range()'s use of SnapshotNonVacuumablesafe during recovery?
От
Peter Geoghegan
Дата:
I noticed that the nbtree README has an obsolete reference to the former design of get_actual_variable_range() in the "Scans during Recovery" section. It used to use a dirty snapshot, but doesn't anymore. These days, get_actual_variable_range() uses SnapshotNonVacuumable -- see commits 3ca930fc and d3751adc. I would like to keep the README current. My understanding is that we can trust RecentGlobalXmin to be something useful and current during recovery, in general, so the selfuncs.c index-only scan (which uses SnapshotNonVacuumable + RecentGlobalXmin) can be trusted to work just as well as it would on the primary. Does that sound correct? The background here is that I plan on finishing off the work started by Simon's commit 3e4b7d87; I want to *completely* remove now-dead code that was used for "recovery pin scans". 3e4b7d87 disabled these "pin scans" without removing them altogether, which just seems sloppy now. There are quite a lot of comments that needlessly talk about this pin scan mechanism in far removed places like nbtxlog.h. Also, we waste a small amount of space in xl_btree_vacuum WAL records, since we don't need to WAL-log lastBlockVacuumed (we also don't need to call _bt_delitems_vacuum() one last time in the case where we don't have anything to kill on the last block, just so the pin scan can happen -- it won't ever happen). -- Peter Geoghegan
Re: Why is get_actual_variable_range()'s use of SnapshotNonVacuumablesafe during recovery?
От
Peter Geoghegan
Дата:
On Wed, Nov 20, 2019 at 1:43 PM Peter Geoghegan <pg@bowt.ie> wrote: > My understanding is that we can trust RecentGlobalXmin to be something > useful and current during recovery, in general, so the selfuncs.c > index-only scan (which uses SnapshotNonVacuumable + RecentGlobalXmin) > can be trusted to work just as well as it would on the primary. Does > that sound correct? Nobody wants to chime in on this? I would like to fix the nbtree README soon. It's kind of standing in the way of my plan to finish off the work started by Simon's commit 3e4b7d87, and remove the remaining remnants of nbtree VACUUM "pin scans". Apart from anything else, the current organisation of the code is contradictory. -- Peter Geoghegan