Re: pgsql: amcheck: Fix verify_heapam for tuples where xmin or xmax is 0. - Mailing list pgsql-committers

From Peter Geoghegan
Subject Re: pgsql: amcheck: Fix verify_heapam for tuples where xmin or xmax is 0.
Date
Msg-id CAH2-WzmEabzcPTxSY-NXKH6Qt3FkAPYHGQSe2PtvGgj17ZQkCw@mail.gmail.com
Whole thread Raw
In response to pgsql: amcheck: Fix verify_heapam for tuples where xmin or xmax is 0.  (Robert Haas <rhaas@postgresql.org>)
List pgsql-committers
On Fri, Mar 24, 2023 at 8:13 AM Robert Haas <rhaas@postgresql.org> wrote:
> If we're checking xmin and find that it is invalid (i.e. 0) just
> report that as corruption, similar to what's already done in the
> three cases that seem correct. If we're checking xmax and find
> that's invalid, that's fine: it just means that the tuple hasn't
> been updated or deleted.

What about aborted speculative insertions? See
heap_abort_speculative(), which directly sets the speculatively
inserted heap tuple's xmin to InvalidTransactionId/zero.

It probably does make sense to keep something close to this check --
it just needs to account for speculative insertions to avoid false
positive reports of corruption. We could perform cross-checks against
a tuple whose xmin is InvalidTransactionId/zero to verify that it
really is from an aborted speculative insertion, to the extent that
that's possible. For example, such a tuple can't be a heap-only tuple,
and it can't have any xmax value other than InvalidTransactionId/zero.

--
Peter Geoghegan



pgsql-committers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: pgsql: Add SysCacheGetAttrNotNull for guaranteed not-null attrs
Next
From: Tomas Vondra
Date:
Subject: Re: pgsql: Fix netmask handling in inet_minmax_multi_ops