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. > + 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)? Otherwise, I guess the only way to be sure is to just reindex every index? Or is this at least specific to b-trees? > + <para> > + Enforce standard locking protocol for TOAST table updates, to prevent > + problems with <command>REINDEX CONCURRENTLY</command> (Michael Paquier) > + </para> > + > + <para> > + If applied to a TOAST table or TOAST table's index, <command>REINDEX > + CONCURRENTLY</command> tended to produce a corrupted index. This > + happened because sessions updating TOAST entries released > + their <literal>ROW EXCLUSIVE</literal> locks immediately, rather > + than holding them until transaction commit as all other updates do. > + The fix is to make TOAST updates hold the table lock according to the > + normal rule. Any existing corrupted indexes can be repaired by > + reindexing again. > + </para> > + </listitem> Same, but at least here the admin can cut it down to only those indexes which were added concurrently. Michael -- Michael Banck Teamleiter PostgreSQL-Team Projektleiter Tel.: +49 2166 9901-171 Email: michael.ba...@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Geoff Richardson, Peter Lilley Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz
