Re: Release notes for February minor releases - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Release notes for February minor releases
Date
Msg-id 20220205221742.qylnkze5ykc4mabv@alap3.anarazel.de
Whole thread Raw
In response to Re: Release notes for February minor releases  (Michael Banck <michael.banck@credativ.de>)
List 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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Synchronizing slots from primary to standby
Next
From: Andres Freund
Date:
Subject: Re: Release notes for February minor releases