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

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