Re: A design for amcheck heapam verification

On Mon, May 1, 2017 at 4:28 PM, Peter Geoghegan <pg(at)bowt(dot)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/