Re: Release notes for February minor releases

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(dot)banck(at)credativ(dot)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