Re: new heapcheck contrib module

On Fri, Jul 31, 2020 at 12:33 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I'm not sure what I was thinking "back then", but right now I'd argue
> that the best lock against vacuum isn't a SUE, but announcing the
> correct ->xmin, so you can be sure that clog entries won't be yanked out
> from under you. Potentially with the right flag sets to avoid old enough
> tuples eing pruned.

Suppose we don't even do anything special in terms of advertising
xmin. What can go wrong? To have a problem, we've got to be running
concurrently with a vacuum that truncates clog. The clog truncation
must happen before our XID lookups, but vacuum has to remove the XIDs
from the heap before it can truncate. So we have to observe the XIDs
before vacuum removes them, but then vacuum has to truncate before we
look them up. But since we observe them and look them up while holding
a ShareLock on the buffer, this seems impossible. What's the flaw in
this argument?

If we do need to do something special in terms of advertising xmin,
how would you do it? Normally it happens by registering a snapshot,
but here all we would have is an XID; specifically, the value of
relfrozenxid that we observed.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company