PG 18 relnotes and RC1

Bruce Momjian <bruce@momjian.us> writes:

Second, the release note item added by this commit:
commit d1073c3b4cc
Author: Peter Eisentraut <peter@eisentraut.org>
Date: Fri Aug 29 10:18:10 2025 +0200

Unfortunately src/tools/add_commit_links.pl can't process the <ulink>
and throws an error because the previous line does not end with a
parenthesis. If I add "()" after the last line in the text block, it
works fine, but obviously this is not acceptable.

I suppose that the expectation is that every release note item
will be credited to someone. Why does this item lack a credit?

If we're okay with items not having credits, then
add_commit_links.pl's logic for where to put the <ulink>s needs
improvement. I don't really understand why it's looking for
parens in the first place -- why isn't the rule simply "put them
before the first </para> in the item"?

In either case, I don't agree with hacky workarounds like manually
munged ulink entries ...

I can commit this once our RC1 git tree freeze is over. Is that Tuesday?

The release freeze doesn't apply to the release notes ;-)

regards, tom lane

I wrote:

If we're okay with items not having credits, then
add_commit_links.pl's logic for where to put the <ulink>s needs
improvement. I don't really understand why it's looking for
parens in the first place -- why isn't the rule simply "put them
before the first </para> in the item"?

I revised the script to do it that way, as attached. The results
don't change in any of our stable branches. In v18, it makes
this change:

diff --git a/doc/src/sgml/release-18.sgml b/doc/src/sgml/release-18.sgml
index c3e318dab00..c49eb2655eb 100644
--- a/doc/src/sgml/release-18.sgml
+++ b/doc/src/sgml/release-18.sgml
@@ -284,7 +284,7 @@ Author: Peter Eisentraut <peter@eisentraut.org>
     database clusters using pg_upgrade, it is recommended to reindex all
     indexes related to full-text search and pg_trgm after the upgrade.

-    <ulink url="&commit_baseurl;fb1a18810f0">&sect;</ulink>
+<ulink url="&commit_baseurl;fb1a18810f0">&sect;</ulink>
     </para>
     </listitem>

because of the blank line before the </para>, which is not our usual
style and should be removed IMO. (Alternatively, we could change
the $prev_leading_space updating logic to ignore blank lines.)

regards, tom lane

On Sat, Aug 30, 2025 at 12:38:06PM -0400, Bruce Momjian wrote:

First, the release notes are incomplete because the "new features and
enhancements" and "Acknowledgments" sections are empty.

Corey Huinker claims to be working on the list of acknowledgments [0]/messages/by-id/CADkLM=e=Rp47yJDteZKMVGpwvNrfcE6GvnN=5chZuzM8jbcVNw@mail.gmail.com, but
I don't see any patches proposed yet. AFAIK nobody has started on the "new
features and enhancements" section.

[0]: /messages/by-id/CADkLM=e=Rp47yJDteZKMVGpwvNrfcE6GvnN=5chZuzM8jbcVNw@mail.gmail.com

--
nathan

On 30 Aug 2025, at 20:51, Nathan Bossart <nathandbossart@gmail.com> wrote:
On Sat, Aug 30, 2025 at 12:38:06PM -0400, Bruce Momjian wrote:

First, the release notes are incomplete because the "new features and
enhancements" and "Acknowledgments" sections are empty.

Corey Huinker claims to be working on the list of acknowledgments [0], but
I don't see any patches proposed yet.

FWIW I have a list of names of v18 contributors put together for an upcoming
talk which I intended to cross-reference against what got proposed here. If
the list is procured in time I can make a patch out of mine.

--
Daniel Gustafsson

On Sat, Aug 30, 2025 at 01:51:23PM -0500, Nathan Bossart wrote:

AFAIK nobody has started on the "new features and enhancements" section.

Quick first attempt:

* btree skip scan
* async i/o
* oauth
* virtual generated columns
* OLD/NEW support in RETURNING
* pg_upgrade improvements (stats, --jobs, --swap)
* EXPLAIN enhancements
* uuidv7
* WITHOUT OVERLAPS/PERIOD

Thoughts?

--
nathan

On Sat, Aug 30, 2025 at 02:42:47PM -0500, Nathan Bossart wrote:

On Sat, Aug 30, 2025 at 01:51:23PM -0500, Nathan Bossart wrote:

AFAIK nobody has started on the "new features and enhancements" section.

Quick first attempt:

* btree skip scan
* async i/o
* oauth
* virtual generated columns
* OLD/NEW support in RETURNING
* pg_upgrade improvements (stats, --jobs, --swap)
* EXPLAIN enhancements
* uuidv7
* WITHOUT OVERLAPS/PERIOD

The 18beta1 announcement [0]https://www.postgresql.org/about/news/postgresql-18-beta-1-released-3070/ has a good list, too. *facepalm* That one
seems to match mine pretty closely.

[0]: https://www.postgresql.org/about/news/postgresql-18-beta-1-released-3070/

--
nathan

On Sat, Aug 30, 2025 at 12:52:45PM -0400, Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

Second, the release note item added by this commit:
commit d1073c3b4cc
Author: Peter Eisentraut <peter@eisentraut.org>
Date: Fri Aug 29 10:18:10 2025 +0200

Unfortunately src/tools/add_commit_links.pl can't process the <ulink>
and throws an error because the previous line does not end with a
parenthesis. If I add "()" after the last line in the text block, it
works fine, but obviously this is not acceptable.

I suppose that the expectation is that every release note item
will be credited to someone. Why does this item lack a credit?

I don't know.

If we're okay with items not having credits, then
add_commit_links.pl's logic for where to put the <ulink>s needs
improvement. I don't really understand why it's looking for
parens in the first place -- why isn't the rule simply "put them
before the first </para> in the item"?

I wrote the code to insert the <ulink> when we are not in a comment,
when the line is a </para>, _and_ the previous line ends with a
parenthesis. Maybe that was overkill, but I wanted to be as restrictive
as possible.

Actually, in this case, it caught an obvious missing attribution, so it
actually helped, so let's not change it. I will add an attribution to
Peter Eisentraut now with the attached patch. I also rewrote the item
to better match the surrounding text.

In either case, I don't agree with hacky workarounds like manually
munged ulink entries ...

I can commit this once our RC1 git tree freeze is over. Is that Tuesday?

The release freeze doesn't apply to the release notes ;-)

Done. ;-)

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Do not let urgent matters crowd out time for investment in the future.

On Sat, Aug 30, 2025 at 02:17:15PM -0400, Tom Lane wrote:

I wrote:

If we're okay with items not having credits, then
add_commit_links.pl's logic for where to put the <ulink>s needs
improvement. I don't really understand why it's looking for
parens in the first place -- why isn't the rule simply "put them
before the first </para> in the item"?

I revised the script to do it that way, as attached. The results
don't change in any of our stable branches. In v18, it makes
this change:

diff --git a/doc/src/sgml/release-18.sgml b/doc/src/sgml/release-18.sgml
index c3e318dab00..c49eb2655eb 100644
--- a/doc/src/sgml/release-18.sgml
+++ b/doc/src/sgml/release-18.sgml
@@ -284,7 +284,7 @@ Author: Peter Eisentraut <peter@eisentraut.org>
database clusters using pg_upgrade, it is recommended to reindex all
indexes related to full-text search and pg_trgm after the upgrade.

-    <ulink url="&commit_baseurl;fb1a18810f0">&sect;</ulink>
+<ulink url="&commit_baseurl;fb1a18810f0">&sect;</ulink>
</para>
</listitem>

because of the blank line before the </para>, which is not our usual
style and should be removed IMO. (Alternatively, we could change
the $prev_leading_space updating logic to ignore blank lines.)

I ran our existing script against all the release notes back to PG 13
and saw no change if we removed the parenthesis check. However, the
check also caught the missing attribution so I am inclined now to change
the script, unless you can explain why we would want to skip the check.

Thanks.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Do not let urgent matters crowd out time for investment in the future.

On Sat, Aug 30, 2025 at 03:02:10PM -0500, Nathan Bossart wrote:

On Sat, Aug 30, 2025 at 02:42:47PM -0500, Nathan Bossart wrote:

On Sat, Aug 30, 2025 at 01:51:23PM -0500, Nathan Bossart wrote:

AFAIK nobody has started on the "new features and enhancements" section.

Quick first attempt:

* btree skip scan
* async i/o
* oauth
* virtual generated columns
* OLD/NEW support in RETURNING
* pg_upgrade improvements (stats, --jobs, --swap)
* EXPLAIN enhancements
* uuidv7
* WITHOUT OVERLAPS/PERIOD

The 18beta1 announcement [0] has a good list, too. *facepalm* That one
seems to match mine pretty closely.

Yes, the list usually comes from the press release.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Do not let urgent matters crowd out time for investment in the future.

Bruce Momjian <bruce@momjian.us> writes:

Actually, in this case, it caught an obvious missing attribution, so it
actually helped, so let's not change it.

Fair enough. I'd still like to put in the bit about

 	my $major_version = $1;
+	die "file name $file is not in the expected format\n"
+	  unless defined $major_version;

because the existing code does not behave nicely at all if you
point it at an incorrect file name.

I will add an attribution to
Peter Eisentraut now with the attached patch. I also rewrote the item
to better match the surrounding text.

Hmm, this text has *two* attributions to Peter, and
add_commit_links.pl disagrees with you on where to put the URL.

regards, tom lane

On Sat, Aug 30, 2025 at 06:04:16PM -0400, Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

Actually, in this case, it caught an obvious missing attribution, so it
actually helped, so let's not change it.

Fair enough. I'd still like to put in the bit about

my $major_version = $1;
+	die "file name $file is not in the expected format\n"
+	  unless defined $major_version;

because the existing code does not behave nicely at all if you
point it at an incorrect file name.

Good fix, done.

I will add an attribution to
Peter Eisentraut now with the attached patch. I also rewrote the item
to better match the surrounding text.

Hmm, this text has *two* attributions to Peter, and
add_commit_links.pl disagrees with you on where to put the URL.

Oops, fixed.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Do not let urgent matters crowd out time for investment in the future.

On Sat, Aug 30, 2025 at 05:56:12PM -0400, Bruce Momjian wrote:

On Sat, Aug 30, 2025 at 03:02:10PM -0500, Nathan Bossart wrote:

The 18beta1 announcement [0] has a good list, too. *facepalm* That one
seems to match mine pretty closely.

Yes, the list usually comes from the press release.

Here is a first attempt at converting the press release into bullet points.

--
nathan

On Aug 30, 2025, at 5:56 PM, Bruce Momjian <bruce@momjian.us> wrote:

On Sat, Aug 30, 2025 at 03:02:10PM -0500, Nathan Bossart wrote:

On Sat, Aug 30, 2025 at 02:42:47PM -0500, Nathan Bossart wrote:
On Sat, Aug 30, 2025 at 01:51:23PM -0500, Nathan Bossart wrote:

AFAIK nobody has started on the "new features and enhancements" section.

Quick first attempt:

* btree skip scan
* async i/o
* oauth
* virtual generated columns
* OLD/NEW support in RETURNING
* pg_upgrade improvements (stats, --jobs, --swap)
* EXPLAIN enhancements
* uuidv7
* WITHOUT OVERLAPS/PERIOD

The 18beta1 announcement [0] has a good list, too. *facepalm* That one
seems to match mine pretty closely.

Yes, the list usually comes from the press release.

I was planning to propose this after I post the GA announcement draft, which I’m finishing up this weekend.

Thanks,

Jonathan

On 30.08.25 18:52, Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

Second, the release note item added by this commit:
commit d1073c3b4cc
Author: Peter Eisentraut <peter@eisentraut.org>
Date: Fri Aug 29 10:18:10 2025 +0200

Unfortunately src/tools/add_commit_links.pl can't process the <ulink>
and throws an error because the previous line does not end with a
parenthesis. If I add "()" after the last line in the text block, it
works fine, but obviously this is not acceptable.

I suppose that the expectation is that every release note item
will be credited to someone. Why does this item lack a credit?

Maybe I'm understanding this differently, but the "Migration" section
ought to be advice about the migration, which is not a place to
communicate credit. In the case I added, the item is the result of some
changes that are already listed and credited elsewhere in the "Changes"
section.

Peter Eisentraut <peter@eisentraut.org> writes:

On 30.08.25 18:52, Tom Lane wrote:

I suppose that the expectation is that every release note item
will be credited to someone. Why does this item lack a credit?

Maybe I'm understanding this differently, but the "Migration" section
ought to be advice about the migration, which is not a place to
communicate credit. In the case I added, the item is the result of some
changes that are already listed and credited elsewhere in the "Changes"
section.

One answer could be to remove the commit-details comment block from
that item, thereby making the added URL go away too. However, that
will look a bit odd when the neighboring items all have credits and
URLs.

I think our past practice has been to list any one item either in
Migration or the following sections, not in both places. This item
seems to adhere to that too: I don't see that commit hash anywhere
else. So I'm not clear why you're finding this duplicative?

regards, tom lane

On Sun, Aug 31, 2025 at 01:34:26PM +0200, Peter Eisentraut wrote:

On 30.08.25 18:52, Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

Second, the release note item added by this commit:
commit d1073c3b4cc
Author: Peter Eisentraut <peter@eisentraut.org>
Date: Fri Aug 29 10:18:10 2025 +0200

Unfortunately src/tools/add_commit_links.pl can't process the <ulink>
and throws an error because the previous line does not end with a
parenthesis. If I add "()" after the last line in the text block, it
works fine, but obviously this is not acceptable.

I suppose that the expectation is that every release note item
will be credited to someone. Why does this item lack a credit?

Maybe I'm understanding this differently, but the "Migration" section ought
to be advice about the migration, which is not a place to communicate
credit. In the case I added, the item is the result of some changes that
are already listed and credited elsewhere in the "Changes" section.

So, this gets back to the the actual purpose of giving credit, and we
have discussed this at length in the past. If an item is worth
mentioning in the release notes because of its impact on users, it is
worth adding attributions, since the attributions are small, and easily
skipped. What I have not done is to add items that do not fit that
criteria solely to give attribution, and that has upset some.

I have used the same criteria in the "Migration" section since I see no
reason to deviate from that policy in that section, and you will see
that in the PG 18 "Migration" section for other items. Years ago, I
think before I was adding commit hashes, I used to not attribute
migration items if they were referenced later, but at this point, with
the need for commit markers anyway, we might as well just repeat the
attribution to keep it consistent.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Do not let urgent matters crowd out time for investment in the future.

On Sun, Aug 31, 2025 at 10:34:43AM -0400, Tom Lane wrote:

Peter Eisentraut <peter@eisentraut.org> writes:

On 30.08.25 18:52, Tom Lane wrote:

I suppose that the expectation is that every release note item
will be credited to someone. Why does this item lack a credit?

Maybe I'm understanding this differently, but the "Migration" section
ought to be advice about the migration, which is not a place to
communicate credit. In the case I added, the item is the result of some
changes that are already listed and credited elsewhere in the "Changes"
section.

One answer could be to remove the commit-details comment block from
that item, thereby making the added URL go away too. However, that
will look a bit odd when the neighboring items all have credits and
URLs.

Yes, and that would make it hard to find the commit used for the change,
which can be helpful for users.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Do not let urgent matters crowd out time for investment in the future.

On 31.08.25 16:34, Tom Lane wrote:

I think our past practice has been to list any one item either in
Migration or the following sections, not in both places. This item
seems to adhere to that too: I don't see that commit hash anywhere
else. So I'm not clear why you're finding this duplicative?

I don't have the complete picture of how the release notes are composed.
I just wanted to add some helpful advice relevant to the migration to
PG18, and the Migration section seemed the right place for it.

Looking at it closer, I think this practice you are describing is
inferior. For one thing, it makes the "Changes" section incomplete: It
should be labeled, "Changes except the ones already listed above". More
importantly, it constrains how the advice in the Migration section can
be structured. It has to be a change description tied to specific
commits and credit, whereas as someone doing the migration, I'm looking
for differently-structured advice.

For example, looking at the item in the Migration section

* Remove column pg_backend_memory_contexts.parent (Melih Mutlu) §

This is no longer needed since pg_backend_memory_contexts.path was
added.

This might be ok as a summary of a description of a code change. But as
someone doing a migration, I don't know what to do with that. If I'm
using PG17 and I'm using the old column, now what?

As another example, the advice on how to handle the change to checksum
enable by default in pg_upgrade is very terse and barely useful.

The Migration section should be written like "If you are using ... then
you should be doing ... {before|after} upgrading."

This can be inferred from many of the items, but several of them not.

On Sun, Aug 31, 2025 at 08:51:40PM +0200, Peter Eisentraut wrote:

On 31.08.25 16:34, Tom Lane wrote:

I think our past practice has been to list any one item either in
Migration or the following sections, not in both places. This item
seems to adhere to that too: I don't see that commit hash anywhere
else. So I'm not clear why you're finding this duplicative?

I don't have the complete picture of how the release notes are composed. I
just wanted to add some helpful advice relevant to the migration to PG18,
and the Migration section seemed the right place for it.

Looking at it closer, I think this practice you are describing is inferior.
For one thing, it makes the "Changes" section incomplete: It should be
labeled, "Changes except the ones already listed above". More importantly,
it constrains how the advice in the Migration section can be structured. It
has to be a change description tied to specific commits and credit, whereas
as someone doing the migration, I'm looking for differently-structured
advice.

For example, looking at the item in the Migration section

* Remove column pg_backend_memory_contexts.parent (Melih Mutlu) §

This is no longer needed since pg_backend_memory_contexts.path was
added.

This might be ok as a summary of a description of a code change. But as
someone doing a migration, I don't know what to do with that. If I'm using
PG17 and I'm using the old column, now what?

As another example, the advice on how to handle the change to checksum
enable by default in pg_upgrade is very terse and barely useful.

The Migration section should be written like "If you are using ... then you
should be doing ... {before|after} upgrading."

This can be inferred from many of the items, but several of them not.

My initial reaction to this is to move "Migration" under "Changes", and
change the "Migration" title to "Changes Affecting Migration".

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Do not let urgent matters crowd out time for investment in the future.