Re: pgsql: amcheck: Fix verify_heapam for tuples where xmin or xmax is 0.

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgsql: amcheck: Fix verify_heapam for tuples where xmin or xmax is 0.
Date: 2023-03-27 17:17:30
Message-ID: CA+TgmobHjMdp+TJKpxAyjqMAuQ5iKfE9HNhaSua2054rbcofdA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Sat, Mar 25, 2023 at 6:25 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> On Fri, Mar 24, 2023 at 8:13 AM Robert Haas <rhaas(at)postgresql(dot)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.

Oh, dear. I didn't know about that case.

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

Since this was back-patched, I think it's probably better to just
remove the error. We can introduce new validation if we want, but that
should probably be master-only.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2023-03-27 17:36:40 pgsql: amcheck: Tighten up validation of redirect line pointers.
Previous Message Daniel Gustafsson 2023-03-27 12:25:06 pgsql: doc: fix Apple Silicon Homebrew prefix change documentation

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-03-27 17:18:50 Re: meson/msys2 fails with plperl/Strawberry
Previous Message Robert Haas 2023-03-27 17:14:15 Re: running logical replication as the subscription owner