Re: new heapcheck contrib module

Hi,

On 2020-07-31 12:42:51 -0400, Robert Haas wrote:
> 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?

The page could have been wrongly marked all-frozen. There could be
interactions between heap and toast table that are checked. Other bugs
could apply, like a broken hot chain or such.

> 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.

An appropriate procarray or snapmgr function would probably suffice?

Greetings,

Andres Freund