Thread: Draft release notes for minor releases are up

Draft release notes for minor releases are up

From
Tom Lane
Date:
First-draft release notes for 16.2 are available at

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=87dcc5e45fad3021514f01360d3a2abd4e6480ee

Please send comments/corrections before Sunday.

            regards, tom lane



Re: Draft release notes for minor releases are up

From
Noah Misch
Date:
On Fri, Feb 02, 2024 at 12:54:48PM -0500, Tom Lane wrote:
> First-draft release notes for 16.2 are available at
> 
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=87dcc5e45fad3021514f01360d3a2abd4e6480ee

> +    <listitem>
> +<!--
> +Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
> +Branch: master [6a1ea02c4] 2024-01-29 13:46:22 +0200
> +Branch: REL_16_STABLE [b899e00e7] 2024-01-29 13:46:30 +0200
> +Branch: REL_15_STABLE [e43425f48] 2024-01-29 13:46:42 +0200
> +Branch: REL_14_STABLE [f120c0872] 2024-01-29 13:46:43 +0200
> +Branch: REL_13_STABLE [e74c91665] 2024-01-29 13:46:45 +0200
> +Branch: REL_12_STABLE [e6511fe64] 2024-01-29 13:46:48 +0200
> +-->
> +     <para>
> +      Fix insufficient locking when cleaning up an incomplete split of
> +      a GIN index's internal page (Fei Changhong, Heikki Linnakangas)
> +     </para>
> +
> +     <para>
> +      The code tried to do this with shared rather than exclusive lock on
> +      the buffer.  This could lead to index corruption if two processes
> +      attempted the cleanup concurrently.
> +     </para>
> +    </listitem>

Shall the top of the notes advise to reindex GIN indexes?

> +    <listitem>
> +<!--
> +Author: Noah Misch <noah@leadboat.com>
> +Branch: master [df220714e] 2024-02-01 13:44:19 -0800
> +Branch: REL_16_STABLE [6d423e9ff] 2024-02-01 13:44:22 -0800
> +Branch: REL_15_STABLE [d493bed28] 2024-02-01 13:44:22 -0800
> +Branch: master [0b6517a3b] 2024-02-01 13:44:19 -0800
> +Branch: REL_16_STABLE [48a6bf5c4] 2024-02-01 13:44:22 -0800
> +Branch: REL_15_STABLE [8fa4a1ac6] 2024-02-01 13:44:23 -0800
> +-->
> +     <para>
> +      Add more interlocks between <command>CREATE DATABASE</command> and
> +      base backup (Noah Misch)
> +     </para>
> +
> +     <para>
> +      This fixes some cases where a base backup taken concurrently
> +      with <command>CREATE DATABASE</command> could produce a corrupt
> +      image of the new database.
> +     </para>
> +    </listitem>

Things I'd like to capture for this one:

- Commit 0b6517a3b deals with crash recovery, not base backups.
- Connection establishment will fail if one of these bugs corrupted the
  database, so there's no need to worry about silent corruption.  (My commit
  messages didn't make that clear.)

Perhaps like this:

diff --git a/doc/src/sgml/release-16.sgml b/doc/src/sgml/release-16.sgml
index 21387e3..8997279 100644
--- a/doc/src/sgml/release-16.sgml
+++ b/doc/src/sgml/release-16.sgml
@@ -750,15 +750,15 @@ Branch: REL_16_STABLE [48a6bf5c4] 2024-02-01 13:44:22 -0800
 Branch: REL_15_STABLE [8fa4a1ac6] 2024-02-01 13:44:23 -0800
 -->
      <para>
-      Add more interlocks between <command>CREATE DATABASE</command> and
-      base backup (Noah Misch)
+      Fix durability of <command>CREATE DATABASE</command> (Noah Misch)
      </para>
 
      <para>
-      This fixes some cases where a base backup taken concurrently
-      with <command>CREATE DATABASE</command> could produce a corrupt
-      image of the new database.
+      Recovery failed, or establishing connections to the new database failed.
+      Effects required an operating system crash or base backup, concurrently
+      with or shortly after the <command>CREATE DATABASE</command>.
      </para>
+
     </listitem>
 
     <listitem>



Re: Draft release notes for minor releases are up

From
Tom Lane
Date:
Noah Misch <noah@leadboat.com> writes:
> Shall the top of the notes advise to reindex GIN indexes?

I thought about that, but it's a pretty low-probability failure
I think, so I didn't write that advice.  Maybe I misjudged it.

> Things I'd like to capture for this one:
> - Commit 0b6517a3b deals with crash recovery, not base backups.
> - Connection establishment will fail if one of these bugs corrupted the
>   database, so there's no need to worry about silent corruption.  (My commit
>   messages didn't make that clear.)
> Perhaps like this:

Thanks, I'll work on that one some more.

            regards, tom lane



Re: Draft release notes for minor releases are up

From
Noah Misch
Date:
On Fri, Feb 02, 2024 at 08:18:50PM -0500, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > Shall the top of the notes advise to reindex GIN indexes?
> 
> I thought about that, but it's a pretty low-probability failure
> I think, so I didn't write that advice.  Maybe I misjudged it.

I can see there being failures so low-probability to omit that text, e.g. a
failure identified theoretically and requiring a process to lose the CPU for
hours.  For this one, the reporter seems to have arrived at it without a
deliberate search.  This one just needs a recovery at the right WAL record,
then two processes reaching the incomplete split concurrently.



Re: Draft release notes for minor releases are up

From
Tom Lane
Date:
Noah Misch <noah@leadboat.com> writes:
> On Fri, Feb 02, 2024 at 08:18:50PM -0500, Tom Lane wrote:
>> Noah Misch <noah@leadboat.com> writes:
>>> Shall the top of the notes advise to reindex GIN indexes?

>> I thought about that, but it's a pretty low-probability failure
>> I think, so I didn't write that advice.  Maybe I misjudged it.

> I can see there being failures so low-probability to omit that text, e.g. a
> failure identified theoretically and requiring a process to lose the CPU for
> hours.  For this one, the reporter seems to have arrived at it without a
> deliberate search.  This one just needs a recovery at the right WAL record,
> then two processes reaching the incomplete split concurrently.

The reporter didn't exactly say, but it did seem that the initial
detection was made without any code modifications, so I take your
point.  I'll add the advice.  Also, I now have this text for your
CREATE DATABASE fixes:

     <para>
      Ensure durability of <command>CREATE DATABASE</command> (Noah Misch)
     </para>

     <para>
      If an operating system crash occurred during or shortly
      after <command>CREATE DATABASE</command>, recovery could fail, or
      subsequent connections to the new database could fail.  If a base
      backup was taken in that window, similar problems could be observed
      when trying to use the backup.  The symptom would be that the
      database directory, <filename>PG_VERSION</filename> file, or
      <filename>pg_filenode.map</filename> file was missing or empty.
     </para>

This is ignoring the point that the set of observable symptoms might
differ between the OS crash and base-backup-recovery cases, but
I'm not sure that that's actually true, and in any case I don't think
it matters for the release notes.

            regards, tom lane



Re: Draft release notes for minor releases are up

From
Noah Misch
Date:
On Sun, Feb 04, 2024 at 01:13:53PM -0500, Tom Lane wrote:
> I now have this text for your CREATE DATABASE fixes:
> 
>      <para>
>       Ensure durability of <command>CREATE DATABASE</command> (Noah Misch)
>      </para>
> 
>      <para>
>       If an operating system crash occurred during or shortly
>       after <command>CREATE DATABASE</command>, recovery could fail, or
>       subsequent connections to the new database could fail.  If a base
>       backup was taken in that window, similar problems could be observed
>       when trying to use the backup.  The symptom would be that the
>       database directory, <filename>PG_VERSION</filename> file, or
>       <filename>pg_filenode.map</filename> file was missing or empty.
>      </para>

Thanks for updating it; this text works for me.

> This is ignoring the point that the set of observable symptoms might
> differ between the OS crash and base-backup-recovery cases, but
> I'm not sure that that's actually true, and in any case I don't think
> it matters for the release notes.

I agree with stopping short of adding that detail; it wouldn't help users make
a known decision.