Why is get_actual_variable_range()'s use of SnapshotNonVacuumablesafe during recovery?
| От | Peter Geoghegan |
|---|---|
| Тема | Why is get_actual_variable_range()'s use of SnapshotNonVacuumablesafe during recovery? |
| Дата | |
| Msg-id | CAH2-Wzn2pSqEOcBDAA40CnO82oEy-EOpE2bNh_XL_cfFoA86jw@mail.gmail.com обсуждение исходный текст |
| Ответы |
Re: Why is get_actual_variable_range()'s use of SnapshotNonVacuumablesafe during recovery?
|
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: