Why is get_actual_variable_range()'s use of SnapshotNonVacuumable safe during recovery?

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Why is get_actual_variable_range()'s use of SnapshotNonVacuumable safe during recovery?
Date: 2019-11-20 21:43:05
Message-ID: CAH2-Wzn2pSqEOcBDAA40CnO82oEy-EOpE2bNh_XL_cfFoA86jw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2019-11-20 21:50:54 BufFileRead() error signalling
Previous Message Tom Lane 2019-11-20 21:34:40 Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?