Re: A design for amcheck heapam verification

Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> If it's not clear what I mean: existing code that cares about
> RecentGlobalXmin is using it as a *conservative* point before which
> every snapshot sees every transaction as committed/aborted (and
> therefore nobody can care if that other backend hot prunes dead tuples
> from before then, or whatever it is). Whereas, amcheck needs to care
> about the possibility that *anyone else* decided that pruning or
> whatever is okay, based on generic criteria, and not what amcheck
> happened to see as RecentGlobalXmin during snapshot acquisition.

ISTM if you want to do that you have an inherent race condition.
That is, no matter what you do, the moment after you look the currently
oldest open transaction could commit, allowing some other session's
view of RecentGlobalXmin to move past what you think it is, so that
that session could start pruning stuff.

Maybe you can fix this by assuming that your own session's advertised xmin
is a safe upper bound on everybody else's RecentGlobalXmin. But I'm not
sure if that rule does what you want.

regards, tom lane