On Mon, May 1, 2017 at 4:28 PM, Peter Geoghegan <p...@bowt.ie> wrote: > Anyone have an opinion on any of this? Offhand, I think that calling > GetOldestXmin() once per index when its "amcheck whole index scan" > finishes would be safe, and yet provide appreciably better test > coverage than only expecting things visible to our original MVCC > snapshot to be present in the index. I don't see a great reason to be > more aggressive and call GetOldestXmin() more often than once per > whole index scan, though.
Wait, that's wrong, because in general RecentGlobalXmin may advance at any time as new snapshots are acquired by other backends. The only thing that we know for sure is that our MVCC snapshot is an interlock against things being recycled that the snapshot needs to see (according to MVCC semantics). And, we don't just have heap pruning to worry about -- we also have nbtree's LP_DEAD based recycling to worry about, before and during the amcheck full index scan (actually, this is probably the main source of problematic recycling for our verification protocol). So, I think that we could call GetOldestXmin() once, provided we were willing to recheck in the style of pg_visibility if and when there was an apparent violation that might be explained as caused by concurrent LP_DEAD recycling within nbtree. That seems complicated enough that I'll never be able to convince myself that it's worthwhile before actually trying to write the code. -- Peter Geoghegan VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
