Re: Release notes for February minor releases

From: Andres Freund <andres(at)anarazel(dot)de>
To: Michael Banck <michael(dot)banck(at)credativ(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Release notes for February minor releases
Date: 2022-02-05 22:17:42
Message-ID: 20220205221742.qylnkze5ykc4mabv@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2022-02-04 22:27:54 +0100, Michael Banck wrote:
> On Fri, Feb 04, 2022 at 02:58:59PM -0500, Tom Lane wrote:
> > I've pushed the first draft for $SUBJECT at
> >
> > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=ab22eea83169c8d0eb15050ce61cbe3d7dae4de6
> >
> > Please send comments/corrections by Sunday.
>
> > + <para>
> > + Fix corruption of HOT chains when a RECENTLY_DEAD tuple changes
> > + state to fully DEAD during page pruning (Andres Freund)
> > + </para>
> > +
> > + <para>
> > + This happens when the last transaction that could <quote>see</quote>
> > + the tuple ends while the page is being pruned. It was then possible
> > + to remove a tuple that is pointed to by a redirect item elsewhere on
> > + the page. While that causes no immediate problem, when the item slot
> > + is re-used by some new tuple, that tuple would be thought to be part
> > + of the pre-existing HOT chain, creating a form of index corruption.
>
> Well, ouchy.

I don't think the above description is quite accurate / makes it sound much
easier to hit than it is.

The time window in which the stars need to align badly is not per-page window,
but per-vacuum. And the window is very narrow. Even if that prerequisite was
fulfilled, one additionally needs to encounter a pretty rare combination of
tids of very specific xid "ages".

> > + If this seems to have affected a table, <command>REINDEX</command>
> > + should repair the damage.
>
> I don't think this is very helpful to the reader, are their indexes
> corrupt or not? If we can't tell them a specific command to run to
> check, can we at least mention that running amcheck would detect that
> (if it actually does)?

It does not reliably. Unfortunately heap amcheck does not verify HOT chains to
any meaningful degree. Nor does btree amcheck check whether index tuples point
to matching heap tuples :(

> Otherwise, I guess the only way to be sure is to
> just reindex every index? Or is this at least specific to b-trees?

It's an issue on the heap side, so unfortunately it is not btree specific.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-02-05 22:58:59 Re: Release notes for February minor releases
Previous Message Andres Freund 2022-02-05 19:59:44 Re: Synchronizing slots from primary to standby