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