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.

On 31.08.25 05:02, Nathan Bossart wrote:

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.

This seems fine. I suggest you commit this, so we get it done.

On Sep 17, 2025, at 2:47 PM, Peter Eisentraut <peter@eisentraut.org> wrote:

On 31.08.25 05:02, Nathan Bossart wrote:

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.

This seems fine. I suggest you commit this, so we get it done.

I had messaged Bruce saying I was going to draft today, latest tomorrow. Please hold off.

Jonathan

On 9/17/25 2:51 PM, Jonathan S. Katz wrote:

On Sep 17, 2025, at 2:47 PM, Peter Eisentraut <peter@eisentraut.org> wrote:

On 31.08.25 05:02, Nathan Bossart wrote:

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.

This seems fine. I suggest you commit this, so we get it done.

I had messaged Bruce saying I was going to draft today, latest tomorrow. Please hold off.

Please see attached draft for the major features of PostgreSQL 18.

Thanks,

Jonathan

Op 9/18/25 om 18:08 schreef Jonathan S. Katz:

Please see attached draft for the major features of PostgreSQL 18.

[...]

[v2-0001-add-major-features-to-v18-release-notes.patch]

One typo:

that can improves throughput should be
that can improve throughput

Erik

On Thu, Sep 18, 2025 at 12:09 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:

Please see attached draft for the major features of PostgreSQL 18.

I like Nathan's version better. I suggest we go with that one.

--
Robert Haas
EDB: http://www.enterprisedb.com

On Sep 18, 2025, at 12:20 PM, Robert Haas <robertmhaas@gmail.com> wrote:

On Thu, Sep 18, 2025 at 12:09 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:

Please see attached draft for the major features of PostgreSQL 18.

I like Nathan's version better. I suggest we go with that one.

Why? This seems arbitrary without more details.

I’ve spent the past several weeks staring at the release notes, talking to users, and putting together a presentation on it that was delivered last night, also culminating in the press release. I put a lot of effort into researching what to highlight up top, which is augmented in the release details itself. Additionally I started from what Nathan had and tweaked a few items.

If there something you specifically disagree with I’d like to better understand.

Jonathan

On Thu, Sep 18, 2025 at 12:59 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:

I like Nathan's version better. I suggest we go with that one.

Why? This seems arbitrary without more details.

I’ve spent the past several weeks staring at the release notes, talking to users, and putting together a presentation on it that was delivered last night, also culminating in the press release. I put a lot of effort into researching what to highlight up top, which is augmented in the release details itself. Additionally I started from what Nathan had and tweaked a few items.

That seems completely backwards to me. We should go with the version
that was submitted weeks ago and upon which people have had the
opportunity to comment unless you can justify each change that you now
want to make at the last minute. Why for example should we drop
mentioning the ability to return OLD.* and NEW.* in favor of mentioned
UUIDv7? I'd argue that the former is more important than the latter,
and I don't see how you can argue otherwise except by appealing to the
research you've done over the last several weeks. But none of us have
access to that or got a vote in it. These things ought to be decided
by consensus. If you want your research to feed into the building of
that consensus, you need to do it and present it earlier. For example,
if you want to present survey results, I think that's a great way to
help decide these kinds of things, but then other people should have
the right to present their own survey results and so on in that
conversation too.

--
Robert Haas
EDB: http://www.enterprisedb.com

On Thu, Sep 18, 2025 at 01:38:44PM -0400, Robert Haas wrote:

That seems completely backwards to me. We should go with the version
that was submitted weeks ago and upon which people have had the
opportunity to comment unless you can justify each change that you now
want to make at the last minute. Why for example should we drop
mentioning the ability to return OLD.* and NEW.* in favor of mentioned
UUIDv7? I'd argue that the former is more important than the latter,
and I don't see how you can argue otherwise except by appealing to the
research you've done over the last several weeks. But none of us have
access to that or got a vote in it. These things ought to be decided
by consensus. If you want your research to feed into the building of
that consensus, you need to do it and present it earlier. For example,
if you want to present survey results, I think that's a great way to
help decide these kinds of things, but then other people should have
the right to present their own survey results and so on in that
conversation too.

Quick analysis of the differences:

Common:
* AIO
* skip scan
* pg_upgrade
* UUIDv7
* virtual generated columns
* OAuth

Only v1 (my patch):
* OLD/NEW for RETURNING
* temporal constraints
* EXPLAIN enhancements

Only v2 (Jonathan's):
* conflict logging

While the EXPLAIN enhancements and conflict logging items seem like super
useful features, I can see how there might be disagreement over whether
they belong in the major features list. I'm a little more surprised about
the omission of OLD/NEW and temporal contraints in v2, though.

That being said, I'm tempted to suggest we UNION the two lists, bikeshed
over the exact wording for a few hours, and then call it day...

--
nathan

On 9/18/25 1:38 PM, Robert Haas wrote:

On Thu, Sep 18, 2025 at 12:59 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:

I like Nathan's version better. I suggest we go with that one.

Why? This seems arbitrary without more details.

I’ve spent the past several weeks staring at the release notes, talking to users, and putting together a presentation on it that was delivered last night, also culminating in the press release. I put a lot of effort into researching what to highlight up top, which is augmented in the release details itself. Additionally I started from what Nathan had and tweaked a few items.

That seems completely backwards to me.

Glad to hear I've been doing my job backwards for years ;) That said, I
am always willing to learn how to improve the process.

We should go with the version
that was submitted weeks ago and upon which people have had the
opportunity to comment unless you can justify each change that you now
want to make at the last minute.

Happy to justify all of this. First, with a few more weeks, we have more
data points on how things are going to be used, so it's OK to make it at
this opint.

Why for example should we drop
mentioning the ability to return OLD.* and NEW.* in favor of mentioned
UUIDv7?

UUIDv7 was in the original one, and it's been carried forward. The
change was I explicitly brought in the function name and the link to it.

I'd argue that the former is more important than the latter,
and I don't see how you can argue otherwise except by appealing to the
research you've done over the last several weeks.

UUIDs are more used way more than RETURNING statements. For example,
last night at the PG18 meetup, everyone's hand went up for using UUIDs,
and no one's hand went up for RETURNING. I did demo that feature last
night and it was pretty cool, and many ORMs use RETURNING on DML
statements to return the info and it's a neat feature. I'm not opposed
to including it in there, but I didn't include it in this draft because
it comes from something that doesn't impact as many users.

That said, if people feel strongly about it, I'm OK to add it back.

But none of us have
access to that or got a vote in it. These things ought to be decided
by consensus. If you want your research to feed into the building of
that consensus, you need to do it and present it earlier.

I posted a patch now; there's still a few days before this is finalized,
and we can iterate on it. The press release was also posted a few weeks
back with time for people to comment on it, too.

This is a task I've helped on every year for nearly a decade and there
have been limited complaints, other than a healthy discussion on what
features should be in the list. For personal reasons I didn't get to
this specific part as early as usual, and given my history of the work
I've done on the release, I would have expected a bit more empathy
towards pulling this together. And of course, I'm always open to
well-stated opinions on what to do.

For example,
if you want to present survey results, I think that's a great way to
help decide these kinds of things, but then other people should have
the right to present their own survey results and so on in that
conversation too.

That's great - your original comment didn't do that though, and I could
have better stated why I put together the list as is.

I will go look at Nathan's original patch one more time at the delta and
post a revision shortly.

Thanks,

Jonathan

On 9/18/25 2:19 PM, Nathan Bossart wrote:

On Thu, Sep 18, 2025 at 01:38:44PM -0400, Robert Haas wrote:

That seems completely backwards to me. We should go with the version
that was submitted weeks ago and upon which people have had the
opportunity to comment unless you can justify each change that you now
want to make at the last minute. Why for example should we drop
mentioning the ability to return OLD.* and NEW.* in favor of mentioned
UUIDv7? I'd argue that the former is more important than the latter,
and I don't see how you can argue otherwise except by appealing to the
research you've done over the last several weeks. But none of us have
access to that or got a vote in it. These things ought to be decided
by consensus. If you want your research to feed into the building of
that consensus, you need to do it and present it earlier. For example,
if you want to present survey results, I think that's a great way to
help decide these kinds of things, but then other people should have
the right to present their own survey results and so on in that
conversation too.

Quick analysis of the differences:

Common:
* AIO
* skip scan
* pg_upgrade
* UUIDv7
* virtual generated columns
* OAuth

Only v1 (my patch):
* OLD/NEW for RETURNING
* temporal constraints
* EXPLAIN enhancements

Only v2 (Jonathan's):
* conflict logging

While the EXPLAIN enhancements and conflict logging items seem like super
useful features, I can see how there might be disagreement over whether
they belong in the major features list. I'm a little more surprised about
the omission of OLD/NEW and temporal contraints in v2, though.

That being said, I'm tempted to suggest we UNION the two lists, bikeshed
over the exact wording for a few hours, and then call it day...

Let's hack on this together for a few and bring a proposal to the list.

Jonathan

On 9/18/25 2:33 PM, Jonathan S. Katz wrote:

On 9/18/25 2:19 PM, Nathan Bossart wrote:

Quick analysis of the differences:

     Common:
     * AIO
     * skip scan
     * pg_upgrade
     * UUIDv7
     * virtual generated columns
     * OAuth

     Only v1 (my patch):
     * OLD/NEW for RETURNING
     * temporal constraints
     * EXPLAIN enhancements

     Only v2 (Jonathan's):
     * conflict logging

While the EXPLAIN enhancements and conflict logging items seem like super
useful features, I can see how there might be disagreement over whether
they belong in the major features list.  I'm a little more surprised
about
the omission of OLD/NEW and temporal contraints in v2, though.

That being said, I'm tempted to suggest we UNION the two lists, bikeshed
over the exact wording for a few hours, and then call it day...

Let's hack on this together for a few and bring a proposal to the list.

Nathan & I hopped on a call to "pair program" on this. Given the point
that his patch had been available on the list for awhile with limited
public comments to date, we did the following:

* Kept everything except EXPLAIN enhancements and conflict logging. For
the former, a lot of this wasn't in the default EXPLAIN path. For the
latter, this was to respect the time period of the discussion.

* Did some minor wordsmithing and linking to help with overall
accessibility, including Erik's typo catch.

Many thanks to Nathan for pulling this together. Please see v3. Feedback
welcome.

Thanks,

Jonathan

On Thu, Sep 18, 2025 at 2:19 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:

Glad to hear I've been doing my job backwards for years ;) That said, I
am always willing to learn how to improve the process.

I don't really care for the flip tone here. I do think there's a
problem here, and I do think it's longstanding. I think it predates
your involvement, but whether it does or not I'd like to fix it.
That's not an accusation that you're doing anything backwards or not,
it's just the facts as I see them.

Why for example should we drop
mentioning the ability to return OLD.* and NEW.* in favor of mentioned
UUIDv7?

UUIDv7 was in the original one, and it's been carried forward. The
change was I explicitly brought in the function name and the link to it.

You're right. That's my mistake.

I posted a patch now; there's still a few days before this is finalized,
and we can iterate on it. The press release was also posted a few weeks
back with time for people to comment on it, too.

This is a task I've helped on every year for nearly a decade and there
have been limited complaints, other than a healthy discussion on what
features should be in the list. For personal reasons I didn't get to
this specific part as early as usual, and given my history of the work
I've done on the release, I would have expected a bit more empathy
towards pulling this together. And of course, I'm always open to
well-stated opinions on what to do.

I am very grateful for all of the work that everyone does to make
releases happen, and I very much appreciate being able to work on a
piece of software that is as great as PostgreSQL without always having
to sweat all the details of getting it out the door. Nevertheless, I
think the problem of the major features list being chronically late is
a longstanding one, and I think we should try to find a way to fix it.

There was one year that Bruce wasn't able to write the release notes
when the community wanted them due to other time commitments and he
disclosed that. We then discussed whether to go with having him do
them at a later time or have someone else do them, and chose the
latter option. I ended up doing them that year. I'm grateful that I
haven't had to do that again because it was a lot of work, but I'm
ALSO grateful that Bruce was upfront about the problem and willing to
cede the responsibility to someone who had more time available during
the critical window. If whatever prevented Bruce from doing the
release notes at the usual time was something deserving of sympathy,
then my sympathy was his for the asking, as is yours. But that is
really a personal conversation that in my view shouldn't have much to
do with how the project assigns tasks. If for example a committer has
a personal issue come up right before feature freeze, we may on a
personal level have a lot of sympathy for them if the result is that
their big feature misses the release, but we have yet to grant a
feature freeze exemption to someone on the basis of something like
that happening, and I don't think we should.

As I see it, while our feature freeze isn't perfect -- mostly because
too many things get slipped in at the last minute that aren't really
in great shape -- it's a lot better than the old process where nobody
really knew what the deadline was. Similarly here, we should just
agree on some deadline for when the PR and major feature tasks should
get completed; and if you or whoever don't think you're going to be
able to make those timelines, then we can either decide on someone
else to do it or we can decide to move the deadline. Either way, if we
do that, we're operating by consensus and a shared set of
expectations.

--
Robert Haas
EDB: http://www.enterprisedb.com

On Thu, Sep 18, 2025 at 03:25:08PM -0400, Robert Haas wrote:

As I see it, while our feature freeze isn't perfect -- mostly because
too many things get slipped in at the last minute that aren't really
in great shape -- it's a lot better than the old process where nobody
really knew what the deadline was. Similarly here, we should just
agree on some deadline for when the PR and major feature tasks should
get completed; and if you or whoever don't think you're going to be
able to make those timelines, then we can either decide on someone
else to do it or we can decide to move the deadline. Either way, if we
do that, we're operating by consensus and a shared set of
expectations.

I think we ought to set a deadline of, say, beta2 or beta3 and have the RMT
responsible for making sure it happens. Either of those releases would
still give us at least a month or so to address feedback before GA, but
they aren't so early as to require lots of rework due to last-minute
changes.

--
nathan

On Thu, Sep 18, 2025 at 3:32 PM Nathan Bossart <nathandbossart@gmail.com> wrote:

I think we ought to set a deadline of, say, beta2 or beta3 and have the RMT
responsible for making sure it happens. Either of those releases would
still give us at least a month or so to address feedback before GA, but
they aren't so early as to require lots of rework due to last-minute
changes.

That would be fine with me. I'd prefer beta2 -- I think it's really
awkward to try to talk up a forthcoming release when the list of major
features is blank for so long, and I think it's nice to give more
people time to bikeshed the list, too, if anyone is inclined to do
that.

--
Robert Haas
EDB: http://www.enterprisedb.com

On 9/18/25 3:25 PM, Robert Haas wrote:

On Thu, Sep 18, 2025 at 2:19 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:

Glad to hear I've been doing my job backwards for years ;) That said, I
am always willing to learn how to improve the process.

I don't really care for the flip tone here.

I didn't really care for your tone with me in the first few emails,
either. I'm glad we agree it's unproductive.

I'm happy to discuss the rest of your note later, as there are valid
points in it. First, let's get this portion of the release done, and
I'll use the time and energy to finish up the rest of the release items
on my plate ahead of the GA.

Jonathan

On 9/18/25 3:32 PM, Nathan Bossart wrote:

On Thu, Sep 18, 2025 at 03:25:08PM -0400, Robert Haas wrote:

As I see it, while our feature freeze isn't perfect -- mostly because
too many things get slipped in at the last minute that aren't really
in great shape -- it's a lot better than the old process where nobody
really knew what the deadline was. Similarly here, we should just
agree on some deadline for when the PR and major feature tasks should
get completed; and if you or whoever don't think you're going to be
able to make those timelines, then we can either decide on someone
else to do it or we can decide to move the deadline. Either way, if we
do that, we're operating by consensus and a shared set of
expectations.

I think we ought to set a deadline of, say, beta2 or beta3 and have the RMT
responsible for making sure it happens. Either of those releases would
still give us at least a month or so to address feedback before GA, but
they aren't so early as to require lots of rework due to last-minute
changes.

I'm OK in theory with pulling in the deadline for the PR and major
features - there is a bunch of work that has to happen after the PR that
is fairly time consuming (translations, website work, feature matrix,
etc.). But let's also look at this holistically, because we had a big
crunch this year with Beta 1 + .dev + out-of-cycle releases that make
this a big crunch.

So, let's have the discussion, but after this GA but before PG19 beta1 :)

Jonathan

On Thu, Sep 18, 2025 at 03:05:52PM -0400, Jonathan S. Katz wrote:

Many thanks to Nathan for pulling this together. Please see v3. Feedback
welcome.

I'm hoping to commit this around 20:00 UTC today, and I will be happy to
address any feedback that folks have in the meantime.

--
nathan

On Fri, Sep 19, 2025 at 09:25:52AM -0500, Nathan Bossart wrote:

I'm hoping to commit this around 20:00 UTC today, and I will be happy to
address any feedback that folks have in the meantime.

Here's a v4. The content is the same except for a typo fix, some
formatting adjustments that don't change anything in the generated page,
and a real commit message. I'm okay with the content, but I figured I'd
note some thoughts:

+      An asynchronous I/O subsystem (AIO) that can improve performance of
+      sequential scans, bitmap heap scans, vacuums, and other operations.

I wondered whether we should put "(AIO)" before "subsystem", but I think
putting it next to "I/O" makes the line too busy. Also, are there "other
operations", or is the rest of the list complete?

+      <link linkend="pgupgrade"><application>pg_upgrade</application></link>
+      now maintains optimizer statistics through upgrade.

I think "retain" might be a better verb than "maintain", but the meaning
seems clear either way. Also, while we could probably omit "through
upgrade", the small amount of redundancy does (IMHO) reinforce the meaning
a bit.

+      Support for "skip scan" lookups that allow
+      <link linkend="indexes-multicolumn">multicolumn B-tree indexes</link> to
+      be used in more cases.

Passive voice. Perhaps this should be "that allow using ... in more
cases."

+      <link linkend="sql-createtable-parms-generated-stored">generated columns</link>
+      that compute their values during read operations.  This is now the
+      default for generated columns.

I liked the phrase "just-in-time" for this because it expresses how it
works. Perhaps we should squeeze that in before "during read operations".

--
nathan

On 9/19/25 12:50 PM, Nathan Bossart wrote:

On Fri, Sep 19, 2025 at 09:25:52AM -0500, Nathan Bossart wrote:

I'm hoping to commit this around 20:00 UTC today, and I will be happy to
address any feedback that folks have in the meantime.

Here's a v4. The content is the same except for a typo fix, some
formatting adjustments that don't change anything in the generated page,
and a real commit message. I'm okay with the content, but I figured I'd
note some thoughts:

+      An asynchronous I/O subsystem (AIO) that can improve performance of
+      sequential scans, bitmap heap scans, vacuums, and other operations.

I wondered whether we should put "(AIO)" before "subsystem", but I think
putting it next to "I/O" makes the line too busy. Also, are there "other
operations", or is the rest of the list complete?

Will throw out the "we can just remove it" option like further down in
the release notes, but figure we've put the AIO terminology out there
enough it may be good to assign the too. Anyway, if we keep it, I'd
suggest "asynchronous I/O (AIO)" given it's modifying that.

For "other operations", the release notes have "etc." in them. But if we
want to hedge, we can do:

...that can improve performance of operations, including sequential
scans, bitmap heap scans, and vacuums."

+      <link linkend="pgupgrade"><application>pg_upgrade</application></link>
+      now maintains optimizer statistics through upgrade.

I think "retain" might be a better verb than "maintain", but the meaning
seems clear either way. Also, while we could probably omit "through
upgrade", the small amount of redundancy does (IMHO) reinforce the meaning
a bit.

OK with "retains", and OK w/dropping "through upgrade".

+      Support for "skip scan" lookups that allow
+      <link linkend="indexes-multicolumn">multicolumn B-tree indexes</link> to
+      be used in more cases.

Passive voice. Perhaps this should be "that allow using ... in more
cases."

Agreed switching to active voice.

+      <link linkend="sql-createtable-parms-generated-stored">generated columns</link>
+      that compute their values during read operations.  This is now the
+      default for generated columns.

I liked the phrase "just-in-time" for this because it expresses how it
works. Perhaps we should squeeze that in before "during read operations".

I think "during" and "just-in-time" are equivalent here. Also wanted to
be sensitive to the fact we already have a feature called
"just-in-time"/"JIT" for compilation, and didn't want people to confuse
the two.

Jonathan

On Fri, Sep 19, 2025 at 01:04:26PM -0400, Jonathan S. Katz wrote:

On 9/19/25 12:50 PM, Nathan Bossart wrote:

+      An asynchronous I/O subsystem (AIO) that can improve performance of
+      sequential scans, bitmap heap scans, vacuums, and other operations.

I wondered whether we should put "(AIO)" before "subsystem", but I think
putting it next to "I/O" makes the line too busy. Also, are there "other
operations", or is the rest of the list complete?

Will throw out the "we can just remove it" option like further down in the
release notes, but figure we've put the AIO terminology out there enough it
may be good to assign the too. Anyway, if we keep it, I'd suggest
"asynchronous I/O (AIO)" given it's modifying that.

Done.

For "other operations", the release notes have "etc." in them. But if we
want to hedge, we can do:

...that can improve performance of operations, including sequential scans,
bitmap heap scans, and vacuums."

I left this alone.

+      <link linkend="pgupgrade"><application>pg_upgrade</application></link>
+      now maintains optimizer statistics through upgrade.

I think "retain" might be a better verb than "maintain", but the meaning
seems clear either way. Also, while we could probably omit "through
upgrade", the small amount of redundancy does (IMHO) reinforce the meaning
a bit.

OK with "retains", and OK w/dropping "through upgrade".

Done.

+      Support for "skip scan" lookups that allow
+      <link linkend="indexes-multicolumn">multicolumn B-tree indexes</link> to
+      be used in more cases.

Passive voice. Perhaps this should be "that allow using ... in more
cases."

Agreed switching to active voice.

Done.

+      <link linkend="sql-createtable-parms-generated-stored">generated columns</link>
+      that compute their values during read operations.  This is now the
+      default for generated columns.

I liked the phrase "just-in-time" for this because it expresses how it
works. Perhaps we should squeeze that in before "during read operations".

I think "during" and "just-in-time" are equivalent here. Also wanted to be
sensitive to the fact we already have a feature called "just-in-time"/"JIT"
for compilation, and didn't want people to confuse the two.

I left this alone, too.

--
nathan

Committed.

--
nathan

On 9/19/25 4:09 PM, Nathan Bossart wrote:

Committed.

Thanks!

Jonathan