Thread: Draft release notes for minor releases are up
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
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>
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
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.
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
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.