Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

doc PG 19 relnotes: remove VALIDATE CONSTRAINT lock item
- 2dab2ce3d781 19 (unreleased) landed
Fix ALTER DOMAIN VALIDATE CONSTRAINT locking
- 64797ad97d6e 19 (unreleased) cited
Revert "Enable fast default for domains with non-volatile constraints"
- a0354e29c41a 19 (unreleased) cited
doc PG 19 relnotes: improve awkward or confusing wording
- eb77a521996f 19 (unreleased) landed
doc PG 19 relnotes: more fixes
- 8656ba7f7187 19 (unreleased) landed
doc PG 19 relnotes: various corrections
- 1d751b4b6b01 19 (unreleased) landed
doc PG 19 relnotes: adjust item to mention pg_replication_slots
- cfedd4513357 19 (unreleased) landed
doc PG 19 relnotes: remove "Add fake LSN support to hash index"
- 41b60bf172ef 19 (unreleased) landed
doc PG 19 relnotes: add two optimizer hooks
- cac0f24eb57f 19 (unreleased) landed
doc PG 19 relnotes: remove "Optionally" for CPU optimizations
- 06fccab4c61b 19 (unreleased) landed
doc PG 19 relnotes: adjustments/removal of items
- 8974a7c433d3 19 (unreleased) landed
doc PG 19 relnotes: add UTF-8 case folding performance item
- 12ca57bf346f 19 (unreleased) landed
doc PG 19 relnotes: correct two items
- 2d773a9f005f 19 (unreleased) landed
doc PG 19 relnotes: add missing commits and details
- 4c0f1e491018 19 (unreleased) landed
doc PG 19 relnotes: fix typo, "date" -> "data"
- 158d8fadd79f 19 (unreleased) landed
doc PG 19 relnotes: add author and move items
- 191a037d4f2d 19 (unreleased) landed
doc PG 19 relnotes: update author
- af1ed03739fb 19 (unreleased) landed
doc PG 19 relnotes: add free space map all-visible item
- be324941262b 19 (unreleased) landed
doc PG 19 relnotes: remove "Lakshmi N" as author of checksums
- 75693dc5b72e 19 (unreleased) landed
doc PG 19 relnotes: fix "now targets"
- caebf165098f 19 (unreleased) landed
doc PG 19 relnotes: adjust ShmemRequestStruct item
- e70ac90d95a2 19 (unreleased) landed
Improve various new-to-v19 appendStringInfo calls
- 49ce41810fac 19 (unreleased) cited
doc: Fix data_checksums data type
- b364828f825a 19 (unreleased) cited
Fix WITHOUT OVERLAPS' interaction with domains.
- 4edd6036d69c 19 (unreleased) cited
Online enabling and disabling of data checksums
- f19c0eccae96 19 (unreleased) cited
Doc: split functions-posix-regexp section into multiple subsections.
- 00c025a00117 19 (unreleased) cited
make immutability tests in to_json and to_jsonb complete
- ecd9288624a1 19 (unreleased) cited
Optimize tuple deformation
- c456e3911380 19 (unreleased) cited
pgstattuple: Optimize pgstattuple_approx() with streaming read
- ae58189a4d52 19 (unreleased) cited
Use fake LSNs to improve nbtree dropPin behavior.
- 8a879119a1d1 19 (unreleased) cited
Use streaming read for VACUUM cleanup of GIN
- 6c228755add8 19 (unreleased) cited
Clean up ICU includes.
- af2d4ca191a4 19 (unreleased) cited
ICU: use UTF8-optimized case conversion API
- c4ff35f10441 19 (unreleased) cited
Add the MODE option to the WAIT FOR LSN command
- 49a181b5d634 19 (unreleased) cited
Speedup tuple deformation with additional function inlining
- 58a359e585d0 18.0 cited

First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-15T01:18:57Z

I have completed the first draft of the PG 19 release notes:

	https://www.postgresql.org/docs/devel/release-19.html

The feature count is 212.  The recent average is 200:

	https://momjian.us/main/writings/pgsql/missing.pdf#page=3

I will create a wiki page to explain my methods used to create this
because, someday, someone else will need to do this.

I am traveling April 19 to May 7, so I might not be able to make quick
adjustments based on feedback.  Another committer can handle them, or
you can wait for me to get to it.

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-15T01:53:50Z

On Tue, Apr 14, 2026 at 09:18:57PM -0400, Bruce Momjian wrote:
> I will create a wiki page to explain my methods used to create this
> because, someday, someone else will need to do this.

Done:

	https://wiki.postgresql.org/wiki/Creating_Major_Release_Notes

-- 
  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.

Re: First draft of PG 19 release notes

Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2026-04-15T02:25:56Z

Hi Bruce,

On Wed, Apr 15, 2026 at 6:49 AM Bruce Momjian <bruce@momjian.us> wrote:
>
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html
>
> The feature count is 212.  The recent average is 200:

One correction:

Add simplified shared memory registration function
ShmemRequestStruct() (Ashutosh Bapat) §

Heikki Linnakangas is the primary author of this commit.

Also, depending upon the availability of space, here's a suggested version:

-- 
Add simplified and improved shared memory registration function
ShmemRequestStruct (Heikki Linnakangas, Ashutosh Bapat)

Allows requesting named shared memory structures during and after
server startup. Functions ShmemInitStruct() and ShmemInitHash() remain
for backward compatibility.
--

-- 
Best Wishes,
Ashutosh Bapat

Re: First draft of PG 19 release notes

David Rowley <dgrowleyml@gmail.com> — 2026-04-15T02:29:49Z

On Wed, 15 Apr 2026 at 13:19, Bruce Momjian <bruce@momjian.us> wrote:
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html

Many thanks for your efforts here.

"Improve performance of internal row formation (David Rowley)"

It's really deformation, not formation. As far as I know, nothing in
v19 sped up tuple formation.

I also think Nathan's work on autovacuum table prioritisation
(d7965d65f) is worth a mention. There were concerns there that it
might cause trouble for people who (for some reason) get best results
from the previous pg_class-ordered priority. Having something in the
notes about this might help direct someone towards why they're seeing
autovacuum behave differently after upgrading.

David

Re: First draft of PG 19 release notes

Peter Smith <smithpb2250@gmail.com> — 2026-04-15T05:27:49Z

Hi,

For this one:
"Allow CREATE/ALTER PUBLICATION to exclude some tables using the
EXCEPT TABLE clause (Vignesh C, Shlok Kyal)"

~

The "EXCEPT TABLE" syntax was later changed to "EXCEPT (TABLE ...)",
so where above says "EXCEPT TABLE clause", probably now that should
just say "EXCEPT clause" same as the documentation.

======
Kind Regards,
Peter Smith.
Fujitsu Australia.

Re: First draft of PG 19 release notes

Laurenz Albe <laurenz.albe@cybertec.at> — 2026-04-15T08:57:25Z

On Tue, 2026-04-14 at 21:18 -0400, Bruce Momjian wrote:
> I have completed the first draft of the PG 19 release notes:
> 
> 	https://www.postgresql.org/docs/devel/release-19.html

Thank you!

I noticed a typo:

  Change vacuumdb's --analyze-only option to analyze partitioned tables when now targets are specified

It should probably be "no targets" rather than "now targets".

Yours,
Laurenz Albe

Re: First draft of PG 19 release notes

Daniel Gustafsson <daniel@yesql.se> — 2026-04-15T11:18:50Z

> On 15 Apr 2026, at 03:18, Bruce Momjian <bruce@momjian.us> wrote:
> 
> I have completed the first draft of the PG 19 release notes:

+Allow online enabling and disabling of data checksums (Daniel Gustafsson, Magnus Hagander, Tomas Vondra, Lakshmi N)

This one should only say "Daniel Gustafsson, Magnus Hagander, Tomas Vondra"

--
Daniel Gustafsson

Re: First draft of PG 19 release notes

jian he <jian.universality@gmail.com> — 2026-04-15T14:59:13Z

On Wed, Apr 15, 2026 at 9:19 AM Bruce Momjian <bruce@momjian.us> wrote:
>
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html
>

https://git.postgresql.org/cgit/postgresql.git/commit/?id=ecd9288624a1582a732cf86ac5a01475a1ce7815
https://git.postgresql.org/cgit/postgresql.git/commit/?id=4edd6036d69ce42ac1af236f659f20daed65c8d4
Do you think these two are worth adding to the release notes?

"""
Allow COPY TO to output partitioned tables (Jian He, Ajin Cherian) § §
Previously COPY (SELECT ...) has to be used to output partitioned tables.
"""
The second commit uses this feature, so i guess the commit message
needs a slight change.

"""
Improve timing performance measurements (Lukas Fittl, Andres Freund,
David Geier, Lukas Fittl, David Geier) § §
This benefits EXPLAIN (ANALYZE, TIMING) and pg_test_timing, and is
controlled via server variable timing_clock_source.
"""
Duplicated name entry.

"""
Allow IS [NOT] DISTINCT FROM NULL to be converted to IS [NOT] NULL for
proven null arguments (Richard Guo) §
The latter form is more easily optimized.
"""
Two optional ``[NOT]`` introduce ambiguity.

"""
Add support for INSERT ... RETURNING ... ON CONFLICT DO SELECT
(Andreas Karlsson, Marko Tiikkaja, Viktor Holmberg) §
This allows conflicting rows to be returns, and optionally locked with
FOR UPDATE/SHARE.
"""
I think it's:
INSERT... ON CONFLICT DO SELECT...RETURNING

--
jian
https://www.enterprisedb.com/

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-15T16:57:21Z

On Wed, Apr 15, 2026 at 07:55:56AM +0530, Ashutosh Bapat wrote:
> Hi Bruce,
> 
> On Wed, Apr 15, 2026 at 6:49 AM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > I have completed the first draft of the PG 19 release notes:
> >
> >         https://www.postgresql.org/docs/devel/release-19.html
> >
> > The feature count is 212.  The recent average is 200:
> 
> One correction:
> 
> Add simplified shared memory registration function
> ShmemRequestStruct() (Ashutosh Bapat) §
> 
> Heikki Linnakangas is the primary author of this commit.
> 
> Also, depending upon the availability of space, here's a suggested version:
> 
> -- 
> Add simplified and improved shared memory registration function
> ShmemRequestStruct (Heikki Linnakangas, Ashutosh Bapat)

I have used your text above.  FYI, the commit message only has this for
author:

	Co-authored-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>

> Allows requesting named shared memory structures during and after
> server startup. Functions ShmemInitStruct() and ShmemInitHash() remain
> for backward compatibility.

I didn't add this text because the number of readers interested in this
change is very small.  Those who are interested can read the commit
message.

-- 
  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.

Re: First draft of PG 19 release notes

Jacob Champion <jacob.champion@enterprisedb.com> — 2026-04-15T17:21:34Z

On Wed, Apr 15, 2026 at 9:57 AM Bruce Momjian <bruce@momjian.us> wrote:
> I have used your text above.  FYI, the commit message only has this for
> author:
>
>         Co-authored-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>

The pattern of "a missing Author means the committer is the primary
author" was discussed at [1]; you asked if Co-authored-by was used
that way, and the answer was "yes". I use it, too.

Thanks,
--Jacob

[1] https://postgr.es/m/adO73c_EJKi05smk%40momjian.us

Re: First draft of PG 19 release notes

Melanie Plageman <melanieplageman@gmail.com> — 2026-04-15T17:56:50Z

On Tue, Apr 14, 2026 at 9:19 PM Bruce Momjian <bruce@momjian.us> wrote:
>
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html

As of b46e1e54d078def, SELECT queries may update the visibility map.
Previously only vacuum did this. I think users may be confused by this
if it is not mentioned in the release notes.

Additionally, users may notice that there are no longer
XLOG_HEAP2_VISIBLE records. A series of commits culminating in
a881cc9c7e819fb (others being d96f87332b378, add323da40a6bf9e0,
1252a4ee2863673, a759ced2f1e) moved VM setting into the
XLOG_HEAP2_PRUNE_VACUUM_SCAN record. Users may notice that
XLOG_HEAP2_VISIBLE records are no longer produced.

This is more minor, but we also now (378a216187aea1) set pd_prune_xid
on insert, so users may notice that a freshly inserted page is
on-access pruned and then the VM is set (which wouldn't have happened
before without vacuum).

- Melanie

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-15T18:41:22Z

On Wed, Apr 15, 2026 at 02:29:49PM +1200, David Rowley wrote:
> On Wed, 15 Apr 2026 at 13:19, Bruce Momjian <bruce@momjian.us> wrote:
> > I have completed the first draft of the PG 19 release notes:
> >
> >         https://www.postgresql.org/docs/devel/release-19.html
> 
> Many thanks for your efforts here.
> 
> "Improve performance of internal row formation (David Rowley)"
> 
> It's really deformation, not formation. As far as I know, nothing in
> v19 sped up tuple formation.

Changed to:

	Improve performance of internal row deformation (David Rowley)
	                                    --
Thanks.

> I also think Nathan's work on autovacuum table prioritisation
> (d7965d65f) is worth a mention. There were concerns there that it
> might cause trouble for people who (for some reason) get best results
> from the previous pg_class-ordered priority. Having something in the
> notes about this might help direct someone towards why they're seeing
> autovacuum behave differently after upgrading.

Yikes, so I collected commits on March 26, but when I went to add new
commits, I used March 27 as the start date, and missed all the late
March 26 commits.  I should have started on March 26 to get
later-in-the-day commits!

I went back and looked at the commits I missed and the one you pointed
out is the only relevant one, so that is good.

Applied patch attached.

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-15T19:27:06Z

On Wed, Apr 15, 2026 at 10:21:34AM -0700, Jacob Champion wrote:
> On Wed, Apr 15, 2026 at 9:57 AM Bruce Momjian <bruce@momjian.us> wrote:
> > I have used your text above.  FYI, the commit message only has this for
> > author:
> >
> >         Co-authored-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
> 
> The pattern of "a missing Author means the committer is the primary
> author" was discussed at [1]; you asked if Co-authored-by was used
> that way, and the answer was "yes". I use it, too.

Well, I am guessing you didn't read this thread fully:

	https://www.postgresql.org/message-id/flat/adElLtegJxi6Yecv%40momjian.us

which opened with the question:

	In the PG 19 commits, I am seeing several commits with Author
	and Co-authored-by tags.  FYI, I think we agreed that only the
	Author names are mentioned as the authors in the release notes.

and I was told that authors and "Co-authored-by" should be listed;  they
are effectively the same, except that github recognizes
"Co-authored-by".

I _thought_ the plan from January 2025 until March 2026 was:

	https://wiki.postgresql.org/wiki/Commit_Message_Guidance
	Author:
	Co-authored-by:
	    Used to indicate the patch authors. "Co-authored-by:" is used by
	    committers when they want to give full credit to the named individuals,
	    but also indicate that they made significant changes.

This was specifically for "Co-authored-by:" == committer, but the text
was not clear enough.  However, that doesn't match your usage where a
missing "Author" is considered to be the committer.

At [1], https://postgr.es/m/adO73c_EJKi05smk, I said: 

	Wow, I never thought that was a valid pattern, but I see a few PG 19
	commit messages using that, e.g.:
	
	
		Author: Peter Eisentraut <peter(at)eisentraut(dot)org>
		2025-08-12 [5f19d13df] libpq: Set LDAP protocol version 3
		
		    libpq: Set LDAP protocol version 3
		
		    Some LDAP servers reject the default version 2 protocol.  So set
		    version 3 before starting the connection.  This matches how the
		    backend LDAP code has worked all along.
		
		    Co-authored-by: Andrew Jackson <andrewjackson947(at)gmail(dot)com>
		    Reviewed-by: Pavel Seleznev <pavel(dot)seleznev(at)gmail(dot)com>
		    Discussion: https://www.postgresql.org/message-id/flat/CAKK5BkHixcivSCA9pfd_eUp7wkLRhvQ6OtGLAYrWC%3Dk7E76LDQ%40mail.gmail.com
	
	
	Is that what people are using?  A missing Author, and co-authors means
	the committer is the author?  Right?  Shouldn't we document this?  That
	does give a unique use for Co-authored-by.

However, later emails said:

	https://www.postgresql.org/message-id/CA%2BTgmob_tz0%2BT1CcyTFwgQVThsoezY2fKib%3Dr%2BukAvVBXwM1gg%40mail.gmail.com
	This whole discussion is crazy to me. Every Author and Co-Author
	should be listed in the release notes. If there is no author or
	co-author named in the commit message, then the committer should be
	listed as the sole author; otherwise, the exact list of authors and
	co-authors that the committer chose to include in the commit message
	should be credited.

and there are more emails saying that, so that is the rule I used, and
documented on the wiki is:

	https://wiki.postgresql.org/wiki/Commit_Message_Guidance
	Used to indicate the patch authors. If no "Author" or
	"Co-authored-by" is listed, the committer is assumed to be
	the author.

What I also said in the thread was:

	What I don't want to do is to re-litigate this again, and usually
	if we ignore what people said in the past, they will show up at
	some later time to try to undo what we are doing now.

I created the PG 19 release notes with Author == "Co-authored-by:", so
if committers have not done that for PG 19, I need them to either inform
me of the rules they used, supply a release note patch, or change the
release notes themselves.  And hopefully use agreed-upon rules in the
future, whatever we decide those are.

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-15T19:34:17Z

On Wed, Apr 15, 2026 at 02:41:22PM -0400, Bruce Momjian wrote:
> On Wed, Apr 15, 2026 at 02:29:49PM +1200, David Rowley wrote:
> > On Wed, 15 Apr 2026 at 13:19, Bruce Momjian <bruce@momjian.us> wrote:
> > > I have completed the first draft of the PG 19 release notes:
> > >
> > >         https://www.postgresql.org/docs/devel/release-19.html
> > 
> > Many thanks for your efforts here.
> > 
> > "Improve performance of internal row formation (David Rowley)"
> > 
> > It's really deformation, not formation. As far as I know, nothing in
> > v19 sped up tuple formation.
> 
> Changed to:
> 
> 	Improve performance of internal row deformation (David Rowley)
> 	                                    --
> Thanks.
> 
> > I also think Nathan's work on autovacuum table prioritisation
> > (d7965d65f) is worth a mention. There were concerns there that it
> > might cause trouble for people who (for some reason) get best results
> > from the previous pg_class-ordered priority. Having something in the
> > notes about this might help direct someone towards why they're seeing
> > autovacuum behave differently after upgrading.
> 
> Yikes, so I collected commits on March 26, but when I went to add new
> commits, I used March 27 as the start date, and missed all the late
> March 26 commits.  I should have started on March 26 to get
> later-in-the-day commits!
> 
> I went back and looked at the commits I missed and the one you pointed
> out is the only relevant one, so that is good.
> 
> Applied patch attached.

Oops, patch _now_ attached.

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-15T19:35:49Z

On Wed, Apr 15, 2026 at 03:27:49PM +1000, Peter Smith wrote:
> Hi,
> 
> For this one:
> "Allow CREATE/ALTER PUBLICATION to exclude some tables using the
> EXCEPT TABLE clause (Vignesh C, Shlok Kyal)"
> 
> ~
> 
> The "EXCEPT TABLE" syntax was later changed to "EXCEPT (TABLE ...)",
> so where above says "EXCEPT TABLE clause", probably now that should
> just say "EXCEPT clause" same as the documentation.

Yep, attached patch applied.

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-15T19:38:02Z

On Wed, Apr 15, 2026 at 10:57:25AM +0200, Laurenz Albe wrote:
> On Tue, 2026-04-14 at 21:18 -0400, Bruce Momjian wrote:
> > I have completed the first draft of the PG 19 release notes:
> > 
> > 	https://www.postgresql.org/docs/devel/release-19.html
> 
> Thank you!
> 
> I noticed a typo:
> 
>   Change vacuumdb's --analyze-only option to analyze partitioned tables when now targets are specified
> 
> It should probably be "no targets" rather than "now targets".

"Now targets" did have a sense of immediacy, but unfortunately
inaccurate.  ;-)   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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-15T19:46:40Z

On Wed, Apr 15, 2026 at 01:18:50PM +0200, Daniel Gustafsson wrote:
> > On 15 Apr 2026, at 03:18, Bruce Momjian <bruce@momjian.us> wrote:
> > 
> > I have completed the first draft of the PG 19 release notes:
> 
> +Allow online enabling and disabling of data checksums (Daniel Gustafsson, Magnus Hagander, Tomas Vondra, Lakshmi N)
> 
> This one should only say "Daniel Gustafsson, Magnus Hagander, Tomas Vondra"

Okay, I added "Lakshmi N" because of this commit which is linked to from
the release notes:

	commit b364828f825
	Author: Daniel Gustafsson <dgustafsson@postgresql.org>
	Date:   Wed Apr 8 22:53:43 2026 +0300
	
	    doc: Fix data_checksums data type
	
	    Commit f19c0eccae96 changed the data_checksums GUC datatype from a
	    boolean to an enum.  This updates the documentation to accurately
	    reflect its new type and document the new possible states: 'on',
	    'off', 'inprogress-on', and 'inprogress-off'.
	
	    Also update the xref for more information to point to the section
	    on data checksums rather than the initdb checksum option.
	
	    Author: Lakshmi N <lakshmin.jhs@gmail.com>
	    Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
	    Discussion:	https://postgr.es/m/CA+3i_M-AtTnqTB2KLBTpu-c-jvnTuy7bGxyxs80rgiQLxWrRUQ@mail.gmail.com

but it is only a small doc patch, so makes sense to remove him.  I
debated this one at the time I added his name.

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-15T20:18:04Z

On Wed, Apr 15, 2026 at 10:59:13PM +0800, jian he wrote:
> On Wed, Apr 15, 2026 at 9:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > I have completed the first draft of the PG 19 release notes:
> >
> >         https://www.postgresql.org/docs/devel/release-19.html
> >
> 
> https://git.postgresql.org/cgit/postgresql.git/commit/?id=ecd9288624a1582a732cf86ac5a01475a1ce7815

I don't usually mention test changes in the release notes.

> https://git.postgresql.org/cgit/postgresql.git/commit/?id=4edd6036d69ce42ac1af236f659f20daed65c8d4

Uh, the commit message is:

	commit 4edd6036d69
	Author: Tom Lane <tgl@sss.pgh.pa.us>
	Date:   Tue Apr 7 14:45:33 2026 -0400
	
	    Fix WITHOUT OVERLAPS' interaction with domains.
	
	    UNIQUE/PRIMARY KEY ... WITHOUT OVERLAPS requires the no-overlap
	    column to be a range or multirange, but it should allow a domain
	    over such a type too.  This requires minor adjustments in both
	    the parser and executor.
	
	    In passing, fix a nearby break-instead-of-continue thinko in
	    transformIndexConstraint.  This had the effect of disabling
	    parse-time validation of the no-overlap column's type in the context
	    of ALTER TABLE ADD CONSTRAINT, if it follows a dropped column.
	    We'd still complain appropriately at runtime though.
	
	    Author: Jian He <jian.universality@gmail.com>
	    Reviewed-by: Paul A Jungwirth <pj@illuminatedcomputing.com>
	    Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
	    Discussion:	https://postgr.es/m/CACJufxGoAmN_0iJ=hjTG0vGpOSOyy-vYyfE+-q0AWxrq2_p5XQ@mail.gmail.com
-->	    Backpatch-through: 18

Since it is backpatched to PG 18, it shouldn't appear in the PG 19
release notes.

> """
> Allow COPY TO to output partitioned tables (Jian He, Ajin Cherian) § §
> Previously COPY (SELECT ...) has to be used to output partitioned tables.
> """
> The second commit uses this feature, so i guess the commit message
> needs a slight change.

Updated in attached patch.

> """
> Improve timing performance measurements (Lukas Fittl, Andres Freund,
> David Geier, Lukas Fittl, David Geier) § §
> This benefits EXPLAIN (ANALYZE, TIMING) and pg_test_timing, and is
> controlled via server variable timing_clock_source.
> """
> Duplicated name entry.

Fixed in attached patch.

> """
> Allow IS [NOT] DISTINCT FROM NULL to be converted to IS [NOT] NULL for
> proven null arguments (Richard Guo) §
> The latter form is more easily optimized.
> """
> Two optional ``[NOT]`` introduce ambiguity.

Uh, if the NOT is in the first, it is in the second.  Is that confusing?
Suggestions?

> """
> Add support for INSERT ... RETURNING ... ON CONFLICT DO SELECT
> (Andreas Karlsson, Marko Tiikkaja, Viktor Holmberg) §
> This allows conflicting rows to be returns, and optionally locked with
> FOR UPDATE/SHARE.
> """
> I think it's:
> INSERT... ON CONFLICT DO SELECT...RETURNING

Uh, went by the commit messsage which says:

	The INSERT statement must have a RETURNING clause, when DO SELECT
	is specified.

However, all the examples have the syntax as you specified, so I must
have interpreted it wrong.

Applied patch attached.

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-15T20:51:16Z

On Wed, Apr 15, 2026 at 01:56:50PM -0400, Melanie Plageman wrote:
> On Tue, Apr 14, 2026 at 9:19 PM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > I have completed the first draft of the PG 19 release notes:
> >
> >         https://www.postgresql.org/docs/devel/release-19.html
> 
> As of b46e1e54d078def, SELECT queries may update the visibility map.
> Previously only vacuum did this. I think users may be confused by this
> if it is not mentioned in the release notes.

Yes, I puzzled on this one and I am glad you clarified its purpose.
I think it should be added, and I have applied the attached patch.

> Additionally, users may notice that there are no longer
> XLOG_HEAP2_VISIBLE records. A series of commits culminating in
> a881cc9c7e819fb (others being d96f87332b378, add323da40a6bf9e0,
> 1252a4ee2863673, a759ced2f1e) moved VM setting into the
> XLOG_HEAP2_PRUNE_VACUUM_SCAN record. Users may notice that
> XLOG_HEAP2_VISIBLE records are no longer produced.
> 
> This is more minor, but we also now (378a216187aea1) set pd_prune_xid
> on insert, so users may notice that a freshly inserted page is
> on-access pruned and then the VM is set (which wouldn't have happened
> before without vacuum).

Uh, I don't want to get into the internals too much in the release
notes, in fear of confusing/losing readers.  I think this is too
low-level to mention, but we now have a good "prune" item so if they see
big improvements, they will know why.

-- 
  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.

Re: First draft of PG 19 release notes

Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2026-04-16T02:22:37Z

On Wed, Apr 15, 2026 at 10:27 PM Bruce Momjian <bruce@momjian.us> wrote:
>
> On Wed, Apr 15, 2026 at 07:55:56AM +0530, Ashutosh Bapat wrote:
> > Hi Bruce,
> >
> > On Wed, Apr 15, 2026 at 6:49 AM Bruce Momjian <bruce@momjian.us> wrote:
> > >
> > > I have completed the first draft of the PG 19 release notes:
> > >
> > >         https://www.postgresql.org/docs/devel/release-19.html
> > >
> > > The feature count is 212.  The recent average is 200:
> >
> > One correction:
> >
> > Add simplified shared memory registration function
> > ShmemRequestStruct() (Ashutosh Bapat) §
> >
> > Heikki Linnakangas is the primary author of this commit.
> >
> > Also, depending upon the availability of space, here's a suggested version:
> >
> > --
> > Add simplified and improved shared memory registration function
> > ShmemRequestStruct (Heikki Linnakangas, Ashutosh Bapat)
>
> I have used your text above.  FYI, the commit message only has this for
> author:
>
>         Co-authored-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>

Thanks for accepting the suggestion.

>
> > Allows requesting named shared memory structures during and after
> > server startup. Functions ShmemInitStruct() and ShmemInitHash() remain
> > for backward compatibility.
>
> I didn't add this text because the number of readers interested in this
> change is very small.  Those who are interested can read the commit
> message.

Fair enough.

-- 
Best Wishes,
Ashutosh Bapat

Re: First draft of PG 19 release notes

Masahiko Sawada <sawada.mshk@gmail.com> — 2026-04-16T05:47:58Z

On Tue, Apr 14, 2026 at 6:19 PM Bruce Momjian <bruce@momjian.us> wrote:
>
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html

Thank you for working on this.

"Add memory usage and parallelism reporting to VACUUM (VERBOSE) and
autovacuum logs (Masahiko Sawada, Daniil Davydov)"

Please revise the author of the memory usage report to vacuum logs to
Tatsuya Kawata. I missed credit him as the author in the original
commit[1].

I've attached the patch.

Regards,

[1] https://www.postgresql.org/message-id/CAD21AoD8NOPCZ6_b0Kt1rdaMtwSU2PaAhwcecEBj4ifEySvLRw%40mail.gmail.com

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

Re: First draft of PG 19 release notes

David Geier <geidav.pg@gmail.com> — 2026-04-16T06:38:45Z

Hi Bruce!

On 15.04.2026 03:18, Bruce Momjian wrote:
> I have completed the first draft of the PG 19 release notes:
> 
> 	https://www.postgresql.org/docs/devel/release-19.html
> 
> The feature count is 212.  The recent average is 200:
> 
> 	https://momjian.us/main/writings/pgsql/missing.pdf#page=3
> 

How about also including the improvements we did for reducing GIN index
build times, see [1]? Not all patches have been committed yet but the
ones that got committed already make a meaningful difference.

[1]
https://www.postgresql.org/message-id/flat/5d366878-2007-4d31-861e-19294b7a583b%40gmail.com

--
David Geier

Re: First draft of PG 19 release notes

Richard Guo <guofenglinux@gmail.com> — 2026-04-16T07:49:37Z

On Wed, Apr 15, 2026 at 10:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html

Thanks for putting in all this work!

The co-author is missing from this item:
* Allow more LEFT JOINs to be converted to ANTI JOINs (Tender Wang)

Three items authored by me are under General Performance but should be
under Optimizer, as they are planner-time expression transformations.
I also fixed some wording issues in those items and one other
Optimizer item.

Attached is the patch.

- Richard

Re: First draft of PG 19 release notes

Michael Banck <mbanck@gmx.net> — 2026-04-16T07:54:57Z

Hi,

On Wed, Apr 15, 2026 at 03:27:06PM -0400, Bruce Momjian wrote:
> On Wed, Apr 15, 2026 at 10:21:34AM -0700, Jacob Champion wrote:
> > On Wed, Apr 15, 2026 at 9:57 AM Bruce Momjian <bruce@momjian.us> wrote:
> > > I have used your text above.  FYI, the commit message only has this for
> > > author:
> > >
> > >         Co-authored-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
> > 
> > The pattern of "a missing Author means the committer is the primary
> > author" was discussed at [1]; you asked if Co-authored-by was used
> > that way, and the answer was "yes". I use it, too.
> 
> Well, I am guessing you didn't read this thread fully:
> 
> 	https://www.postgresql.org/message-id/flat/adElLtegJxi6Yecv%40momjian.us
> 
> which opened with the question:
> 
> 	In the PG 19 commits, I am seeing several commits with Author
> 	and Co-authored-by tags.  FYI, I think we agreed that only the
> 	Author names are mentioned as the authors in the release notes.
> 
> and I was told that authors and "Co-authored-by" should be listed;  they
> are effectively the same, except that github recognizes
> "Co-authored-by".
> 
> I _thought_ the plan from January 2025 until March 2026 was:
> 
> 	https://wiki.postgresql.org/wiki/Commit_Message_Guidance
> 	Author:
> 	Co-authored-by:
> 	    Used to indicate the patch authors. "Co-authored-by:" is used by
> 	    committers when they want to give full credit to the named individuals,
> 	    but also indicate that they made significant changes.
> 
> This was specifically for "Co-authored-by:" == committer, but the text
> was not clear enough.  However, that doesn't match your usage where a
> missing "Author" is considered to be the committer.

I think if the committer omits an "Author" tag, but credits a
non-committer as "Co-Author", then both the committer and the
non-committer should be considered authors and credited in the release
notes.

What would be the use-case for a sole non-committer "Co-Author" (as
opposed to just crediting the non-committer as "Author") otherwise be?


Michael

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-16T15:13:51Z

On Thu, Apr 16, 2026 at 09:54:57AM +0200, Michael Banck wrote:
> > Well, I am guessing you didn't read this thread fully:
> > 
> > 	https://www.postgresql.org/message-id/flat/adElLtegJxi6Yecv%40momjian.us
> >
> > This was specifically for "Co-authored-by:" == committer, but the text
> > was not clear enough.  However, that doesn't match your usage where a
> > missing "Author" is considered to be the committer.
> 
> I think if the committer omits an "Author" tag, but credits a
> non-committer as "Co-Author", then both the committer and the
> non-committer should be considered authors and credited in the release
> notes.
> 
> What would be the use-case for a sole non-committer "Co-Author" (as
> opposed to just crediting the non-committer as "Author") otherwise be?

I agree with you, and made that case in January of 2025 and in the email
thread URL above.  However, I seemed to annoy people more than help
them, so I am not going to revisit it.  If someone else wants to restart
that thread and get a different consensus, feel free to do so.

My guess is that most (vocal?) committers prefer to have Author and
Co-Author indicate different levels of authorship in the commit text,
rather than have them have different behavior for release note
authorship.

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-16T15:24:05Z

On Wed, Apr 15, 2026 at 10:47:58PM -0700, Masahiko Sawada wrote:
> On Tue, Apr 14, 2026 at 6:19 PM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > I have completed the first draft of the PG 19 release notes:
> >
> >         https://www.postgresql.org/docs/devel/release-19.html
> 
> Thank you for working on this.
> 
> "Add memory usage and parallelism reporting to VACUUM (VERBOSE) and
> autovacuum logs (Masahiko Sawada, Daniil Davydov)"
> 
> Please revise the author of the memory usage report to vacuum logs to
> Tatsuya Kawata. I missed credit him as the author in the original
> commit[1].
> 
> I've attached the patch.

Great, patch applied.

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-16T16:14:04Z

On Thu, Apr 16, 2026 at 08:38:45AM +0200, David Geier wrote:
> Hi Bruce!
> 
> On 15.04.2026 03:18, Bruce Momjian wrote:
> > I have completed the first draft of the PG 19 release notes:
> > 
> > 	https://www.postgresql.org/docs/devel/release-19.html
> > 
> > The feature count is 212.  The recent average is 200:
> > 
> > 	https://momjian.us/main/writings/pgsql/missing.pdf#page=3
> > 
> 
> How about also including the improvements we did for reducing GIN index
> build times, see [1]? Not all patches have been committed yet but the
> ones that got committed already make a meaningful difference.
> 
> [1]
> https://www.postgresql.org/message-id/flat/5d366878-2007-4d31-861e-19294b7a583b%40gmail.com

This is an interesting case.  First, I looked at the commit logs and
didn't see anything talking about improving the speed of GIN index
builds.  So then I looked at the first email in the thread and saw 3x
improvement for pg_trgm, so I looked in the commit logs for pg_trgm and
didn't see any speedup mentioned.

I then looked at the posted patches and this might be a case where there
are a number of targeted improvements that didn't specify the larger
goal, so there is no goal mentioned in the commit logs.  This is an edge
case that is hard to get into the release notes.

Now that you have told me about it, here is my normal criteria for
adding performance items to the release notes:

	Performance improvements are mentioned in the release notes if
	they are user-visible (e.g., new syntax) or significant enough
	to enable new workloads.

So, it seems there is no user-visible change, except it is faster.  Does
it enable new workloads?  A 3x speedup probably does.  Should this be a
pg_trgm item, with a description mentioning GIN in general, or should it
be a GIN item, perhaps mentioning pg_trgm?  Do you have any suggested
text and list of commits?

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-16T16:45:50Z

On Thu, Apr 16, 2026 at 04:49:37PM +0900, Richard Guo wrote:
> On Wed, Apr 15, 2026 at 10:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> > I have completed the first draft of the PG 19 release notes:
> >
> >         https://www.postgresql.org/docs/devel/release-19.html
> 
> Thanks for putting in all this work!
> 
> The co-author is missing from this item:
> * Allow more LEFT JOINs to be converted to ANTI JOINs (Tender Wang)
> 
> Three items authored by me are under General Performance but should be
> under Optimizer, as they are planner-time expression transformations.
> I also fixed some wording issues in those items and one other
> Optimizer item.
> 
> Attached is the patch.

Great, patch applied.

-- 
  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.

Re: First draft of PG 19 release notes

David Geier <geidav.pg@gmail.com> — 2026-04-17T14:40:09Z

On 16.04.2026 18:14, Bruce Momjian wrote:
>> How about also including the improvements we did for reducing GIN index
>> build times, see [1]? Not all patches have been committed yet but the
>> ones that got committed already make a meaningful difference.
>>
>> [1]
>> https://www.postgresql.org/message-id/flat/5d366878-2007-4d31-861e-19294b7a583b%40gmail.com
> 
> This is an interesting case.  First, I looked at the commit logs and
> didn't see anything talking about improving the speed of GIN index
> builds.  So then I looked at the first email in the thread and saw 3x
> improvement for pg_trgm, so I looked in the commit logs for pg_trgm and
> didn't see any speedup mentioned.
> 
> I then looked at the posted patches and this might be a case where there
> are a number of targeted improvements that didn't specify the larger
> goal, so there is no goal mentioned in the commit logs.  This is an edge
> case that is hard to get into the release notes.
> 
> Now that you have told me about it, here is my normal criteria for
> adding performance items to the release notes:
> 
> 	Performance improvements are mentioned in the release notes if
> 	they are user-visible (e.g., new syntax) or significant enough
> 	to enable new workloads.
> 
> So, it seems there is no user-visible change, except it is faster.  Does
> it enable new workloads?  A 3x speedup probably does.  Should this be a
> pg_trgm item, with a description mentioning GIN in general, or should it
> be a GIN item, perhaps mentioning pg_trgm?  Do you have any suggested
> text and list of commits?

Not all patches from the initial mail have been committed yet. Hence,
currently the speed up is less. However, once they got all committed
they would indeed open up new "use cases". For example, I know users
that don't add GIN indexes to very large tables because creating them
takes too long.

--
David Geier

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-17T14:44:22Z

On Fri, Apr 17, 2026 at 04:40:09PM +0200, David Geier wrote:
> > Now that you have told me about it, here is my normal criteria for
> > adding performance items to the release notes:
> > 
> > 	Performance improvements are mentioned in the release notes if
> > 	they are user-visible (e.g., new syntax) or significant enough
> > 	to enable new workloads.
> > 
> > So, it seems there is no user-visible change, except it is faster.  Does
> > it enable new workloads?  A 3x speedup probably does.  Should this be a
> > pg_trgm item, with a description mentioning GIN in general, or should it
> > be a GIN item, perhaps mentioning pg_trgm?  Do you have any suggested
> > text and list of commits?
> 
> Not all patches from the initial mail have been committed yet. Hence,
> currently the speed up is less. However, once they got all committed
> they would indeed open up new "use cases". For example, I know users
> that don't add GIN indexes to very large tables because creating them
> takes too long.

Yes, GIN index creation has always been considered slow, so it is good
it is being worked on.  I wonder if we should just wait for it all to be
committed before adding it to the release notes, unless you want to
measure the improvement we have in PG 19.

-- 
  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.

Re: First draft of PG 19 release notes

David Geier <geidav.pg@gmail.com> — 2026-04-19T11:27:10Z

>>> So, it seems there is no user-visible change, except it is faster.  Does
>>> it enable new workloads?  A 3x speedup probably does.  Should this be a
>>> pg_trgm item, with a description mentioning GIN in general, or should it
>>> be a GIN item, perhaps mentioning pg_trgm?  Do you have any suggested
>>> text and list of commits?
>>
>> Not all patches from the initial mail have been committed yet. Hence,
>> currently the speed up is less. However, once they got all committed
>> they would indeed open up new "use cases". For example, I know users
>> that don't add GIN indexes to very large tables because creating them
>> takes too long.
> 
> Yes, GIN index creation has always been considered slow, so it is good
> it is being worked on.  I wonder if we should just wait for it all to be
> committed before adding it to the release notes, unless you want to
> measure the improvement we have in PG 19.

I've measured with the same benchmark I used in the original thread [1].
With latest master the results are as follows:

Dataset  | REL_18_3   | master     | Speedup
---------|------------|------------|--------
movies   |  10,561 ms |   9,124 ms | 1.17x
lineitem | 263,523 ms | 234,605 ms | 1.12x

That's because three patches from the patchset haven't been committed
yet. Two of the three patches are the most impactful from the patchset.

[1]
https://www.postgresql.org/message-id/flat/5d366878-2007-4d31-861e-19294b7a583b%40gmail.com

--
David Geier

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-19T13:32:45Z

On Sun, Apr 19, 2026 at 01:27:10PM +0200, David Geier wrote:
> >>> So, it seems there is no user-visible change, except it is faster.  Does
> >>> it enable new workloads?  A 3x speedup probably does.  Should this be a
> >>> pg_trgm item, with a description mentioning GIN in general, or should it
> >>> be a GIN item, perhaps mentioning pg_trgm?  Do you have any suggested
> >>> text and list of commits?
> >>
> >> Not all patches from the initial mail have been committed yet. Hence,
> >> currently the speed up is less. However, once they got all committed
> >> they would indeed open up new "use cases". For example, I know users
> >> that don't add GIN indexes to very large tables because creating them
> >> takes too long.
> > 
> > Yes, GIN index creation has always been considered slow, so it is good
> > it is being worked on.  I wonder if we should just wait for it all to be
> > committed before adding it to the release notes, unless you want to
> > measure the improvement we have in PG 19.
> 
> I've measured with the same benchmark I used in the original thread [1].
> With latest master the results are as follows:
> 
> Dataset  | REL_18_3   | master     | Speedup
> ---------|------------|------------|--------
> movies   |  10,561 ms |   9,124 ms | 1.17x
> lineitem | 263,523 ms | 234,605 ms | 1.12x
> 
> That's because three patches from the patchset haven't been committed
> yet. Two of the three patches are the most impactful from the patchset.

Okay, at +12-17%, so we should wait until all the patches are in to
mention this.  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.

Re: First draft of PG 19 release notes

Andres Freund <andres@anarazel.de> — 2026-04-19T15:10:40Z

Hi,

On 2026-04-19 09:32:45 -0400, Bruce Momjian wrote:
> On Sun, Apr 19, 2026 at 01:27:10PM +0200, David Geier wrote:
> > >>> So, it seems there is no user-visible change, except it is faster.  Does
> > >>> it enable new workloads?  A 3x speedup probably does.  Should this be a
> > >>> pg_trgm item, with a description mentioning GIN in general, or should it
> > >>> be a GIN item, perhaps mentioning pg_trgm?  Do you have any suggested
> > >>> text and list of commits?
> > >>
> > >> Not all patches from the initial mail have been committed yet. Hence,
> > >> currently the speed up is less. However, once they got all committed
> > >> they would indeed open up new "use cases". For example, I know users
> > >> that don't add GIN indexes to very large tables because creating them
> > >> takes too long.
> > > 
> > > Yes, GIN index creation has always been considered slow, so it is good
> > > it is being worked on.  I wonder if we should just wait for it all to be
> > > committed before adding it to the release notes, unless you want to
> > > measure the improvement we have in PG 19.
> > 
> > I've measured with the same benchmark I used in the original thread [1].
> > With latest master the results are as follows:
> > 
> > Dataset  | REL_18_3   | master     | Speedup
> > ---------|------------|------------|--------
> > movies   |  10,561 ms |   9,124 ms | 1.17x
> > lineitem | 263,523 ms | 234,605 ms | 1.12x
> > 
> > That's because three patches from the patchset haven't been committed
> > yet. Two of the three patches are the most impactful from the patchset.
> 
> Okay, at +12-17%, so we should wait until all the patches are in to
> mention this.  Thanks.

That makes no sense to me.  It's a material improvement that could convince
people to upgrade.  Why would you not want to mention that, just because PG 20
might have further improvements? There *always* will be further potential
improvements.

Greetings,

Andres Freund

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-19T17:53:08Z

On Sun, Apr 19, 2026 at 11:10:40AM -0400, Andres Freund wrote:
> Hi,
> 
> On 2026-04-19 09:32:45 -0400, Bruce Momjian wrote:
> > On Sun, Apr 19, 2026 at 01:27:10PM +0200, David Geier wrote:
> > > >>> So, it seems there is no user-visible change, except it is faster.  Does
> > > >>> it enable new workloads?  A 3x speedup probably does.  Should this be a
> > > >>> pg_trgm item, with a description mentioning GIN in general, or should it
> > > >>> be a GIN item, perhaps mentioning pg_trgm?  Do you have any suggested
> > > >>> text and list of commits?
> > > >>
> > > >> Not all patches from the initial mail have been committed yet. Hence,
> > > >> currently the speed up is less. However, once they got all committed
> > > >> they would indeed open up new "use cases". For example, I know users
> > > >> that don't add GIN indexes to very large tables because creating them
> > > >> takes too long.
> > > > 
> > > > Yes, GIN index creation has always been considered slow, so it is good
> > > > it is being worked on.  I wonder if we should just wait for it all to be
> > > > committed before adding it to the release notes, unless you want to
> > > > measure the improvement we have in PG 19.
> > > 
> > > I've measured with the same benchmark I used in the original thread [1].
> > > With latest master the results are as follows:
> > > 
> > > Dataset  | REL_18_3   | master     | Speedup
> > > ---------|------------|------------|--------
> > > movies   |  10,561 ms |   9,124 ms | 1.17x
> > > lineitem | 263,523 ms | 234,605 ms | 1.12x
> > > 
> > > That's because three patches from the patchset haven't been committed
> > > yet. Two of the three patches are the most impactful from the patchset.
> > 
> > Okay, at +12-17%, so we should wait until all the patches are in to
> > mention this.  Thanks.
> 
> That makes no sense to me.  It's a material improvement that could convince
> people to upgrade.  Why would you not want to mention that, just because PG 20
> might have further improvements? There *always* will be further potential
> improvements.

The text I put in the wiki, which I have followed for years, says:

	https://wiki.postgresql.org/wiki/Creating_Major_Release_Notes
	Performance improvements are mentioned in the release notes if
	they are user-visible (e.g., new syntax) or significant enough
	to enable new workloads.

I didn't think +12-17% for an index build would enable new workloads. 
If you want to relitigate that, you are welcome to do so.  If this is
changed, it has to be done so consistently, not just for this item.

-- 
  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.

Re: First draft of PG 19 release notes

Andres Freund <andres@anarazel.de> — 2026-04-19T18:04:34Z

Hi,

On 2026-04-19 13:53:08 -0400, Bruce Momjian wrote:
> The text I put in the wiki, which I have followed for years, says:
>
> 	https://wiki.postgresql.org/wiki/Creating_Major_Release_Notes
> 	Performance improvements are mentioned in the release notes if
> 	they are user-visible (e.g., new syntax) or significant enough
> 	to enable new workloads.
>
> I didn't think +12-17% for an index build would enable new workloads.
> If you want to relitigate that, you are welcome to do so.  If this is
> changed, it has to be done so consistently, not just for this item.

Just about everyone has disagreed vehemently with you about this, in every of
the last 5 releases or so.  I don't think it's ok that you continue to ignore
that.

I find this policy so depressing that I stopped even opening the release
notes, just to preserve whatever semblance of sanity I possess.  I'm know I'm
not alone in that.

Greetings,

Andres Freund

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-19T18:36:57Z

On Sun, Apr 19, 2026 at 02:04:34PM -0400, Andres Freund wrote:
> Hi,
> 
> On 2026-04-19 13:53:08 -0400, Bruce Momjian wrote:
> > The text I put in the wiki, which I have followed for years, says:
> >
> > 	https://wiki.postgresql.org/wiki/Creating_Major_Release_Notes
> > 	Performance improvements are mentioned in the release notes if
> > 	they are user-visible (e.g., new syntax) or significant enough
> > 	to enable new workloads.
> >
> > I didn't think +12-17% for an index build would enable new workloads.
> > If you want to relitigate that, you are welcome to do so.  If this is
> > changed, it has to be done so consistently, not just for this item.
> 
> Just about everyone has disagreed vehemently with you about this, in every of
> the last 5 releases or so.  I don't think it's ok that you continue to ignore
> that.

That is not my recollection, and I thought I would have heard more about
it if that was the case.

> I find this policy so depressing that I stopped even opening the release
> notes, just to preserve whatever semblance of sanity I possess.  I'm know I'm
> not alone in that.

Well, I just merged the wiki text to explain that we have to consider
how much an item is of interest when adding it:

	While the major release notes include changes to the documented
	extension interface, it does not include all changes of interest
	to extension developers or Postgres forks because doing so would
	include too many items that would be uninteresting to the general
	audience.  Performance improvements are mentioned in the release
	notes if they are user-visible (e.g., new syntax) or significant
	enough to enable new workloads.

So, if you want to change this process, please feel free to get
agreement on new text that I can follow, or someone else can follow.

I have always hesitated to expand the list of items with concern that
general Postgres users will lose interest in reading it.  I have in mind
that the release notes are not for me or hackers subscribers to read.

I think we expanded the the list for optimizer changes.  Could we find a
way to do that more that would be readable?  I don't know.

-- 
  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.

Re: First draft of PG 19 release notes

Andres Freund <andres@anarazel.de> — 2026-04-19T19:25:42Z

On 2026-04-19 14:36:57 -0400, Bruce Momjian wrote:
> On Sun, Apr 19, 2026 at 02:04:34PM -0400, Andres Freund wrote:
> > Hi,
> > 
> > On 2026-04-19 13:53:08 -0400, Bruce Momjian wrote:
> > > The text I put in the wiki, which I have followed for years, says:
> > >
> > > 	https://wiki.postgresql.org/wiki/Creating_Major_Release_Notes
> > > 	Performance improvements are mentioned in the release notes if
> > > 	they are user-visible (e.g., new syntax) or significant enough
> > > 	to enable new workloads.
> > >
> > > I didn't think +12-17% for an index build would enable new workloads.
> > > If you want to relitigate that, you are welcome to do so.  If this is
> > > changed, it has to be done so consistently, not just for this item.
> > 
> > Just about everyone has disagreed vehemently with you about this, in every of
> > the last 5 releases or so.  I don't think it's ok that you continue to ignore
> > that.
> 
> That is not my recollection, and I thought I would have heard more about
> it if that was the case.

I don't know what to tell you. Just looking at emails to you with a subject
that contains release and a body that contains performance quickly unearthed:

Tom:
https://postgr.es/m/568104.1716520270@sss.pgh.pa.us

Jonathan:
https://postgr.es/m/29a7dd7b-cb55-4c3c-8eba-faeca222b10b@postgresql.org

Alvaro:
https://postgr.es/m/202405150838.sg5ddcexyyf4@alvherre.pgsql

David:
https://postgr.es/m/CAApHDvrun6b+cAj6bgb6_1irnu+t7GU_uCdj1XvMQsPT0KngkQ@mail.gmail.com

Melanie:
https://postgr.es/m/CAAKRu_YKDQG1qA-eRq+gf5uoXZ3s9Jm3af9k3yF7WdKr2eTqLA@mail.gmail.com

Joe:
https://postgr.es/m/c276a2e5-a7ef-410d-832e-6fe54137e86d@joeconway.com

Jelte:
https://postgr.es/m/CAGECzQTp5TW+YzihDdPDuZN6q_uNWL_iCi5uxN2AjGPLOJh=Mg@mail.gmail.com

Peter G:
https://postgr.es/m/CAH2-Wzkgyak_ni0u24r1v3nhM1gVfx68-7-ZX1yZB+zcojMdnw@mail.gmail.com

Robert:
https://postgr.es/m/CA+TgmobqYx=+1RDsD7w9r_pfTa-CgJ6_Aj0SNaA6UKHQGyT9vg@mail.gmail.com

Noah:
20180505061321.GA2832545@rfd.leadboat.com

me:
https://postgr.es/m/20240524175028.lul7tpbngjlemy7j@awork3.anarazel.de


That's just a small sample.  I think nearly everybody said so in multiple
releases.  The argument goes back to at least 9.5...




> > I find this policy so depressing that I stopped even opening the release
> > notes, just to preserve whatever semblance of sanity I possess.  I'm know I'm
> > not alone in that.
> 
> Well, I just merged the wiki text to explain that we have to consider
> how much an item is of interest when adding it:
> 
> 	While the major release notes include changes to the documented
> 	extension interface, it does not include all changes of interest
> 	to extension developers or Postgres forks because doing so would
> 	include too many items that would be uninteresting to the general
> 	audience.  Performance improvements are mentioned in the release
> 	notes if they are user-visible (e.g., new syntax) or significant
> 	enough to enable new workloads.

I think you're again documenting things as consensus for which there is not
concensus.


> So, if you want to change this process, please feel free to get
> agreement on new text that I can follow, or someone else can follow.

s/if they are user-visible (e.g., new syntax) or//
s/enough to enable new workloads//


> I have always hesitated to expand the list of items with concern that
> general Postgres users will lose interest in reading it.  I have in mind
> that the release notes are not for me or hackers subscribers to read.

Yes, which is precisely why they should be able to read the release notes to
see if an upgrade might address their performance issue. They can't
realistically be expected to read all commit messages or the list.


> I think we expanded the the list for optimizer changes.  Could we find a
> way to do that more that would be readable?  I don't know.

I don't think mentioning a few performance improvements when we do mention
things like "Modify psql backslash commands to show comments", "Allow the
search path to appear in the psql prompt via "%S", "Add IO wait events for
COPY FROM/TO on a pipe/file/program", ... makes a material negative
difference.

If we want to make the release notes easier to grasp, I could imagine that
giving each bullet point an icon indicating whether it's a feature, a
performance improvement, a behavioural change or such could make it easier to
scan.

Greetings,

Andres Freund

Re: First draft of PG 19 release notes

David Rowley <dgrowleyml@gmail.com> — 2026-04-20T01:30:25Z

On Mon, 20 Apr 2026 at 07:25, Andres Freund <andres@anarazel.de> wrote:
>
> On 2026-04-19 14:36:57 -0400, Bruce Momjian wrote:
> > That is not my recollection, and I thought I would have heard more about
> > it if that was the case.
>
> I don't know what to tell you. Just looking at emails to you with a subject
> that contains release and a body that contains performance quickly unearthed:

> David:
> https://postgr.es/m/CAApHDvrun6b+cAj6bgb6_1irnu+t7GU_uCdj1XvMQsPT0KngkQ@mail.gmail.com

This isn't a "I told you so" comment, but I do feel that it's hard to
unsee the irony in the originally omitted item being discussed there
(tidstore), which in the end was the top-listed headline feature for
v17. I feel that was just too powerful a signal to how much others do
think this stuff is worthwhile mentioning.

> > I have always hesitated to expand the list of items with concern that
> > general Postgres users will lose interest in reading it.  I have in mind
> > that the release notes are not for me or hackers subscribers to read.

There is a "General Performance" section for this, so maybe people who
don't care about performance can skip these more easily.

I do agree that there is some threshold. Sometimes we do commit
patches which we know increases performance some way, but nobody
tested by how much. There are likely many of these, but one example
[1] that I don't think has any business on the release notes, but it
should help performance somehow/somewhere. It just might or might not
be measurable. Filtering out those seems good.

Maybe there's something committers can put in the commit message to
make it more obvious which commits matter by referencing some actual
performance numbers that were published that showed a definitive
speedup (not just a measurment of noise). I do expect that it's a
fairly horrible job if we're going to ask Bruce to trawl each thread
to find what performance numbers were posted. In the past I've tried
to list some example numbers in commit messages to help Bruce (e.g.
final paragraph in [2] and [3]). I'm not sure if it does help, or if
there's something better that could be done instead.

David

[1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=49ce41810faca2722424b3d8fabda79bf4902339
[2] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=c456e39113809376f6604e720910ccd24e18e034
[3] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=58a359e585d0281ecab4d34cab9869e7eb4e4ca3

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-20T09:10:54Z

On Mon, Apr 20, 2026 at 01:30:25PM +1200, David Rowley wrote:
> Maybe there's something committers can put in the commit message to
> make it more obvious which commits matter by referencing some actual
> performance numbers that were published that showed a definitive
> speedup (not just a measurement of noise). I do expect that it's a
> fairly horrible job if we're going to ask Bruce to trawl each thread
> to find what performance numbers were posted. In the past I've tried
> to list some example numbers in commit messages to help Bruce (e.g.
> final paragraph in [2] and [3]). I'm not sure if it does help, or if
> there's something better that could be done instead.

In that thread from PG 17, I said:

https://www.postgresql.org/message-id/ZlKaHOM8HYLy9nCY%40momjian.us

> Well, let's start with a new section for PG 17 that lists these.  Is it
> 20 items, 50, or 150?  I have no idea, but without the user-visible
> filter, I am unable to determine what not-included performance features
> are worthy of the release notes.
> 
> Can someone do that?  There is no reason other committers can't change
> the release notes.  Yes, I realize we are looking for a consistent
> voice, but the new section can probably have its own style, and I can
> make adjustments if desired.
> 
> Also, I think this has gone unaddressed so long because if we skip a
> user-visible change, users complain, but I don't remember anyone
> complaining about skipped performance changes.

So, what is the filter I am supposed to use?  We even have a patch that,
in aggregate, increases performance by 12-17%.  Is that under or over
the threadshold to be included?  I have no idea.  And, even if we agree
on a number, how do I handle commits with no numbers;  this commit
didn't have a number.

Just like with the co-authored-by, I need rules.  I thought I got
agreement on the co-authored-by rules in January 2025 because no one
objected, only to learn recently that many didn't like it, and we
changed the rules, and I used those new rules for PG 19.

I can follow the rules on the wiki:

	https://wiki.postgresql.org/wiki/Creating_Major_Release_Notes
	While the major release notes include changes to the documented
	extension interface, it does not include all changes of interest
	to extension developers or Postgres forks because doing so would
	include too many items that would be uninteresting to the general
	audience.  Similarly, performance improvements are not mentioned in
	the release notes unless they are user-visible (e.g., new syntax)
	or significant enough to enable new workloads.

I can't follow rules that require me to consistently identify if a patch
is a performance improvement, and if it is significant enough for the
release notes.  If someone else can do that, please go ahead and stop
blaming me for something I can't do.  I thought if it was easy, someone
else since PG 17 would have either given me rules or done it.

Can committers mention when they want something to be included in the
release notes?  What we can do is to have all the hackers point out the
missing items after I done creating the release notes, as messy as that
is.

One thing we can easily do is to add text to the release notes stating,
"This release includes minor performance improvements that are too
numerous to mention."

-- 
  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.

Re: First draft of PG 19 release notes

shammat@gmx.net — 2026-04-20T10:07:55Z

Bruce Momjian schrieb am 15.04.2026 um 03:18:
> I have completed the first draft of the PG 19 release notes:
> 
> 	https://www.postgresql.org/docs/devel/release-19.html
> 
> The feature count is 212.  The recent average is 200:
> 
> 	https://momjian.us/main/writings/pgsql/missing.pdf#page=3
> 
> I will create a wiki page to explain my methods used to create this
> because, someday, someone else will need to do this.
> 
> I am traveling April 19 to May 7, so I might not be able to make quick
> adjustments based on feedback.  Another committer can handle them, or
> you can wait for me to get to it.
> 


"Allow casts between bytea and uuid date types"

I think that should be "data" types?

Re: First draft of PG 19 release notes

David Rowley <dgrowleyml@gmail.com> — 2026-04-20T10:40:13Z

On Mon, 20 Apr 2026 at 21:10, Bruce Momjian <bruce@momjian.us> wrote:
> In that thread from PG 17, I said:
>
> https://www.postgresql.org/message-id/ZlKaHOM8HYLy9nCY%40momjian.us
>
> > Well, let's start with a new section for PG 17 that lists these.  Is it
> > 20 items, 50, or 150?  I have no idea, but without the user-visible
> > filter, I am unable to determine what not-included performance features
> > are worthy of the release notes.

I imagine it's easier to prune away items that are not interesting
enough than to add ones that were skipped. Unless we get visibility of
ones that you skipped, it requires someone else to notice something is
missing (probably their own work), or it requires a complete parse of
all commits in the release.

> So, what is the filter I am supposed to use?  We even have a patch that,
> in aggregate, increases performance by 12-17%.  Is that under or over
> the threadshold to be included?  I have no idea.  And, even if we agree
> on a number, how do I handle commits with no numbers;  this commit
> didn't have a number.

That's going to be tricky to define. 2x performance increase in
something like initdb isn't going to be nearly as interesting to an
end user as making joins or aggregation go twice as fast. Maybe it
would be worth putting temporary tags on items that there are no
obvious performance numbers for to tell the author or committer that
you need proof, otherwise the item might disappear. For items that
might be more borderline worth adding, maybe those could also get
added and tagged to trigger some debate as to if they're worth keeping
around. In the end, we might see what it is you see with the bloated
release notes. You might find you get more agreement to remove things.
That's seldom requested with the current method. It seems reasonable
that not many people can sympathise with the "there are too many
items" problem, as by the time the notes go public, they're already
trimmed down to a manageable number. We might find that we all agree
on more things if the pruning is done more publicly.

> I can't follow rules that require me to consistently identify if a patch
> is a performance improvement, and if it is significant enough for the
> release notes.  If someone else can do that, please go ahead and stop
> blaming me for something I can't do.  I thought if it was easy, someone
> else since PG 17 would have either given me rules or done it.

I don't think anyone expects you to do anything that makes this job
harder than it already.  I expect a careful process change could make
this job easier for you.

> Can committers mention when they want something to be included in the
> release notes?  What we can do is to have all the hackers point out the
> missing items after I done creating the release notes, as messy as that
> is.

I wondered if the job could be made easier if we were to tag fixup
commits for commits that fix some recent feature commit. You could
pretty much ignore every single one of those for the release notes. If
that fixup information was more structured, it might also be very
interesting.

> One thing we can easily do is to add text to the release notes stating,
> "This release includes minor performance improvements that are too
> numerous to mention."

If the WIP draft contained the items of lesser importance, we might be
able to do some aggregation of those into something meaningful enough.
It might be much easier for people closer to the particular items to
aggregate them than it is for a single person to do it for all
commits. I'm aware that you already do quite a bit of this aggregation
already.

David

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-20T11:15:36Z

On Mon, Apr 20, 2026 at 12:07:55PM +0200, shammat@gmx.net wrote:
> Bruce Momjian schrieb am 15.04.2026 um 03:18:
> > I have completed the first draft of the PG 19 release notes:
> > 
> > 	https://www.postgresql.org/docs/devel/release-19.html
> > 
> > The feature count is 212.  The recent average is 200:
> > 
> > 	https://momjian.us/main/writings/pgsql/missing.pdf#page=3
> > 
> > I will create a wiki page to explain my methods used to create this
> > because, someday, someone else will need to do this.
> > 
> > I am traveling April 19 to May 7, so I might not be able to make quick
> > adjustments based on feedback.  Another committer can handle them, or
> > you can wait for me to get to it.
> > 
> 
> 
> "Allow casts between bytea and uuid date types"
> 
> I think that should be "data" types? 

Yes, fixed 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.

Re: First draft of PG 19 release notes

Xuneng Zhou <xunengzhou@gmail.com> — 2026-04-20T13:03:41Z

Hi Bruce,

On Wed, Apr 15, 2026 at 9:19 AM Bruce Momjian <bruce@momjian.us> wrote:
>
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html
>
> The feature count is 212.  The recent average is 200:
>
>         https://momjian.us/main/writings/pgsql/missing.pdf#page=3
>
> I will create a wiki page to explain my methods used to create this
> because, someday, someone else will need to do this.
>
> I am traveling April 19 to May 7, so I might not be able to make quick
> adjustments based on feedback.  Another committer can handle them, or
> you can wait for me to get to it.

Thanks for working on the draft. Here're some comments for it:

1) Improve performance of pgstattuple by using streaming reads

There are two related commits that improve the performance of
pgstattuple. The current hyperlink references [1]; would it make sense
to include [2] too?

[1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=213f0079b
[2] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=ae58189a4d523f0156ebe30f4534180555669e88

2) Additionally, would this[3] be something worth mentioning in the
General Performance section? The improvement looks fairly big.

[3] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=6c228755add8f0714677440d53a160f9ed332902

3) Allow standbys to wait for LSN values to be replayed via WAIT FOR
As for this feature, the follow-up commit[4] extends the WAIT FOR
command to support waiting for flush and write operations. Is it
helpful for users to be aware of these use cases as well?

[4] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=49a181b5d634340fcfb7c762c387c03f6405367e

Thanks!

-- 
Best,
Xuneng

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-20T16:12:07Z

On Mon, Apr 20, 2026 at 10:40:13PM +1200, David Rowley wrote:
> That's going to be tricky to define. 2x performance increase in
> something like initdb isn't going to be nearly as interesting to an
> end user as making joins or aggregation go twice as fast. Maybe it
> would be worth putting temporary tags on items that there are no
> obvious performance numbers for to tell the author or committer that
> you need proof, otherwise the item might disappear. For items that
> might be more borderline worth adding, maybe those could also get
> added and tagged to trigger some debate as to if they're worth keeping
> around. In the end, we might see what it is you see with the bloated
> release notes. You might find you get more agreement to remove things.
> That's seldom requested with the current method. It seems reasonable
> that not many people can sympathise with the "there are too many
> items" problem, as by the time the notes go public, they're already
> trimmed down to a manageable number. We might find that we all agree
> on more things if the pruning is done more publicly.

So, these are not really rules, but a suggestion to just include more
and we can trim.  I see several problems with that:

1.  Researching and writing each item is what takes the most time, so it
could double my time to do this, which is fine if there were not other
problems.

2.  I don't think people will be motived to remove items, partly because
they might not want to upset anyone, and partly because they might
assume everyone else knows more.  This could lead to the item count
doubling, not because we want all those items but because we can't trim,
and I would be embarrassed to be part of that and would probably stop
being involved.

3.  My guess of what to add would be very poor.  I can mostly guess new
workload performance items, but once it gets more granular than that, I
would guess poorly and don't want to field complaints about my poor
guesses.

I asked in the PG 17 thread for someone to create a list of missing
items, and that was mostly successful.  Another approach would be for me
to create a document with the git detail of all commits I didn't include
--- that is easy to do since I have the commit hashes in the XML files,
and people can then look at that and tell me which commits need to be
added.

It is only April 20.  We still have time for someone to start from
scratch and make a new version.

-- 
  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.

Re: First draft of PG 19 release notes

Etsuro Fujita <etsuro.fujita@gmail.com> — 2026-04-21T12:24:59Z

On Wed, Apr 15, 2026 at 10:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html

Thank you!

"Allow the retrieval of statistics from foreign data wrapper servers
(Corey Huinker, Etsuro Fujita)"

This is mentioned in the Additional Modules section, presumably
because it was supported in postgres_fdw, but it isn't limited to
postgres_fdw, so we should move it to the General Performance section?

Best regards,
Etsuro Fujita

Re: First draft of PG 19 release notes

Andres Freund <andres@anarazel.de> — 2026-04-21T15:52:37Z

Hi,

On 2026-04-20 12:12:07 -0400, Bruce Momjian wrote:
> On Mon, Apr 20, 2026 at 10:40:13PM +1200, David Rowley wrote:
> > That's going to be tricky to define. 2x performance increase in
> > something like initdb isn't going to be nearly as interesting to an
> > end user as making joins or aggregation go twice as fast. Maybe it
> > would be worth putting temporary tags on items that there are no
> > obvious performance numbers for to tell the author or committer that
> > you need proof, otherwise the item might disappear. For items that
> > might be more borderline worth adding, maybe those could also get
> > added and tagged to trigger some debate as to if they're worth keeping
> > around. In the end, we might see what it is you see with the bloated
> > release notes. You might find you get more agreement to remove things.
> > That's seldom requested with the current method. It seems reasonable
> > that not many people can sympathise with the "there are too many
> > items" problem, as by the time the notes go public, they're already
> > trimmed down to a manageable number. We might find that we all agree
> > on more things if the pruning is done more publicly.
> 
> So, these are not really rules, but a suggestion to just include more
> and we can trim.  I see several problems with that:
> 
> 1.  Researching and writing each item is what takes the most time, so it
> could double my time to do this, which is fine if there were not other
> problems.

FWIW, I think it's totally fine if you say that you don't want to do the work
to formulate performance improvement release note entries.  It's a lot of work
to curate the release notes, it makes sense to split the work up.

It's just that the answer to proposing listing certain performance
improvements shouldn't be that we don't include them as a matter of policy.


> It is only April 20.  We still have time for someone to start from
> scratch and make a new version.

I don't see any need to start from scratch! That'd be foolish imo, it's a lot
of work to get to this point.

Greetings,

Andres Freund

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-21T20:18:40Z

On Mon, Apr 20, 2026 at 10:40:13PM +1200, David Rowley wrote:
> > I can't follow rules that require me to consistently identify if a patch
> > is a performance improvement, and if it is significant enough for the
> > release notes.  If someone else can do that, please go ahead and stop
> > blaming me for something I can't do.  I thought if it was easy, someone
> > else since PG 17 would have either given me rules or done it.
> 
> I don't think anyone expects you to do anything that makes this job
> harder than it already.  I expect a careful process change could make
> this job easier for you.
> 
> > Can committers mention when they want something to be included in the
> > release notes?  What we can do is to have all the hackers point out the
> > missing items after I done creating the release notes, as messy as that
> > is.
> 
> I wondered if the job could be made easier if we were to tag fixup
> commits for commits that fix some recent feature commit. You could
> pretty much ignore every single one of those for the release notes. If
> that fixup information was more structured, it might also be very
> interesting.
> 
> > One thing we can easily do is to add text to the release notes stating,
> > "This release includes minor performance improvements that are too
> > numerous to mention."
> 
> If the WIP draft contained the items of lesser importance, we might be
> able to do some aggregation of those into something meaningful enough.
> It might be much easier for people closer to the particular items to
> aggregate them than it is for a single person to do it for all
> commits. I'm aware that you already do quite a bit of this aggregation
> already.

I had some more time to think about the items you list above.  My first
reaction was that it wasn't workable, but I then realized it is not
workable because you can't do this level of analysis once the release
note items are written.  This idea of aggregating items and getting
people to choose items makes a lot of sense if we are using a list of
commits with git commit text that were not included already.

Let me work on creating such a list and we will see how it goes.  I am
traveling now so it will be delayed.

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-21T20:28:09Z

On Tue, Apr 21, 2026 at 11:52:37AM -0400, Andres Freund wrote:
> On 2026-04-20 12:12:07 -0400, Bruce Momjian wrote:
> > So, these are not really rules, but a suggestion to just include more
> > and we can trim.  I see several problems with that:
> > 
> > 1.  Researching and writing each item is what takes the most time, so it
> > could double my time to do this, which is fine if there were not other
> > problems.
> 
> FWIW, I think it's totally fine if you say that you don't want to do the work
> to formulate performance improvement release note entries.  It's a lot of work
> to curate the release notes, it makes sense to split the work up.

When people complained about missing optimizer improvements, I was able
to add them by referencing the plan changes they effect, with the
assumption that they understand plan types.  For lower-level performance
improvements, it is nearly impossible for me to explain the items in a
way that references something the reader will understand.  Saying "widget
X is faster" when the user has no idea what X is just isn't useful
information for them, and I can't even explain widget X in a brief,
user-relatable way.  It is this fundamental issue that has prevented me
from even trying.

In summary, I was only able to do the optimizer additions by referencing
plan types --- if I didn't assume users understand plan types, adding
the optimizer issues would also have been impossible for me.  I think
David Rowley's idea of rolling up performance improvements into a single
release note entry that is relatable is a great idea, but something I am
incapable of doing without a lot of help.  Giving a list of commits and
git details might allow others to create text for such items.

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-21T20:41:36Z

On Tue, Apr 21, 2026 at 11:52:37AM -0400, Andres Freund wrote:
> FWIW, I think it's totally fine if you say that you don't want to do the work
> to formulate performance improvement release note entries.  It's a lot of work
> to curate the release notes, it makes sense to split the work up.
> 
> It's just that the answer to proposing listing certain performance
> improvements shouldn't be that we don't include them as a matter of policy.

I am fine with listing anything, as long as it is effective and useful
to the reader.  I explained in my recent email why I considered that to
be very hard for performance items, but with help I think it can be
achieved.  New optimizer items are a good example --- we reference plan
types.  I need help in how other items can have similar effectiveness.

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-21T21:17:13Z

On Tue, Apr 21, 2026 at 04:18:40PM -0400, Bruce Momjian wrote:
> Let me work on creating such a list and we will see how it goes.  I am
> traveling now so it will be delayed.

That was easy with awk, so done and attached.  There are 1556 commits
from the start of PG 19 to the AS OF date of the release notes that I
did not include in the release notes.

-- 
  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.

Re: First draft of PG 19 release notes

jian he <jian.universality@gmail.com> — 2026-04-22T03:10:06Z

On Wed, Apr 15, 2026 at 9:19 AM Bruce Momjian <bruce@momjian.us> wrote:
>
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html
>

Change FDW function prototypes to use uint* instead of bit* typedefs
(Nathan Bossart) §
This commit doesn't seem related to FDW?

Allow btree_gin to match partial qualifications (Tom Lane) § §
I don't understand "partial qualifications", the commit seems more
about "cross type operators".

https://git.postgresql.org/cgit/postgresql.git/commit/?id=999f172d
Can this also be added to the release notes?

Do you think this
(https://git.postgresql.org/cgit/postgresql.git/commit/?id=00c025a001170979e99706ce746f75fcc615761d)
worth add to the release notes?

Before commit:
https://www.postgresql.org/docs/current/functions-matching.html#FUNCTIONS-POSIX-REGEXP
After commit:
https://www.postgresql.org/docs/devel/functions-matching.html#FUNCTIONS-POSIX-LIST

--
jian
https://www.enterprisedb.com/

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-22T07:11:23Z

On Tue, Apr 21, 2026 at 05:17:13PM -0400, Bruce Momjian wrote:
> On Tue, Apr 21, 2026 at 04:18:40PM -0400, Bruce Momjian wrote:
> > Let me work on creating such a list and we will see how it goes.  I am
> > traveling now so it will be delayed.
> 
> That was easy with awk, so done and attached.  There are 1556 commits
> from the start of PG 19 to the AS OF date of the release notes that I
> did not include in the release notes.

Here is a better version with the "[DOC]" marker I use.

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-04-23T15:10:03Z

On Wed, Apr 22, 2026 at 03:11:23AM -0400, Bruce Momjian wrote:
> On Tue, Apr 21, 2026 at 05:17:13PM -0400, Bruce Momjian wrote:
> > On Tue, Apr 21, 2026 at 04:18:40PM -0400, Bruce Momjian wrote:
> > > Let me work on creating such a list and we will see how it goes.  I am
> > > traveling now so it will be delayed.
> > 
> > That was easy with awk, so done and attached.  There are 1556 commits
> > from the start of PG 19 to the AS OF date of the release notes that I
> > did not include in the release notes.
> 
> Here is a better version with the "[DOC]" marker I use.

I documented how I created this "excluded commits" list as item 12 here:

	https://wiki.postgresql.org/wiki/Creating_Major_Release_Notes

-- 
  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.

Re: First draft of PG 19 release notes

Andreas Karlsson <andreas@proxel.se> — 2026-04-30T07:08:58Z

On 4/15/26 3:18 AM, Bruce Momjian wrote:
> I have completed the first draft of the PG 19 release notes:

Thanks!

I noticed that two of my performance patches were not included in the 
release notes and I personally think one of them belongs in the release 
notes while other not.

The one I think belongs is the one below since it it really results in 
major speedups of lower(), upper(), initcap() and casefold() on ICU with 
UTF-8. Not having to convert from UTF-8 to UTF-32 and back is often a 
major speedup.

commit c4ff35f10441de7dbed4e87737bca205dcca698e
Author: Jeff Davis <jdavis@postgresql.org>
Date:   Tue Jan 6 14:09:07 2026 -0800

     ICU: use UTF8-optimized case conversion API

     Initializes a UCaseMap object once for use across calls, and uses
     UTF8-optimized APIs.

     Author: Andreas Karlsson <andreas@proxel.se>
     Reviewed-by: zengman <zengman@halodbtech.com>
     Discussion: 
https://postgr.es/m/5a010b27-8ed9-4739-86fe-1562b07ba564@proxel.se

-- 
Andreas Karlsson
Percona

Re: First draft of PG 19 release notes

Andreas Karlsson <andreas@proxel.se> — 2026-04-30T07:16:59Z

On 4/30/26 9:08 AM, Andreas Karlsson wrote:
> I noticed that two of my performance patches were not included in the 
> release notes and I personally think one of them belongs in the release 
> notes while other not.
> 
> The one I think belongs is the one below since it it really results in 
> major speedups of lower(), upper(), initcap() and casefold() on ICU with 
> UTF-8. Not having to convert from UTF-8 to UTF-32 and back is often a 
> major speedup.

Saw the big discussion on performance improvements if they should be 
included or not. So I will just leave this alone. :)

-- 
Andreas Karlsson
Percona

Re: First draft of PG 19 release notes

Richard Guo <guofenglinux@gmail.com> — 2026-05-01T01:16:24Z

On Wed, Apr 15, 2026 at 10:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html

I just committed 8d829f5a0 to fix JSON_ARRAY(subquery) to return an
empty JSON array instead of NULL over an empty result set, per the
SQL/JSON standard.  Since this is a user-visible behavior change, we
need to add an item to the v19 migration section to call it out.

Suggested entry:

 - Make JSON_ARRAY(query_expression) return an empty JSON array when
   the subquery returns no rows (Richard Guo)

   Previously, an empty result set produced NULL.  This corrects the
   behavior to match the SQL/JSON standard.  Application code that
   relied on the previous NULL behavior may need to be updated.

- Richard

RE: First draft of PG 19 release notes

Phil Florent <philflorent@hotmail.com> — 2026-05-01T13:24:51Z

Hi,
I see on many UTF-8 customer bases expression-based index on lower(col) to fulfill some ORM implementation (lower(col) = lower(exp) or "ilike" but ilike is even more "difficult" to index so lower(col) is not so bad...) If pg 19 makes lower(utf-8_text) faster, it's definitely something I would be happy to read in a major upgrade .
Best regards,
Phil

________________________________
De : Andreas Karlsson <andreas@proxel.se>
Envoyé : jeudi 30 avril 2026 09:16
À : Bruce Momjian <bruce@momjian.us>; PostgreSQL-development <pgsql-hackers@lists.postgresql.org>
Objet : Re: First draft of PG 19 release notes

On 4/30/26 9:08 AM, Andreas Karlsson wrote:
> I noticed that two of my performance patches were not included in the
> release notes and I personally think one of them belongs in the release
> notes while other not.
>
> The one I think belongs is the one below since it it really results in
> major speedups of lower(), upper(), initcap() and casefold() on ICU with
> UTF-8. Not having to convert from UTF-8 to UTF-32 and back is often a
> major speedup.

Saw the big discussion on performance improvements if they should be
included or not. So I will just leave this alone. :)

--
Andreas Karlsson
Percona

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-05-07T20:20:38Z

On Thu, Apr 23, 2026 at 11:10:03AM -0400, Bruce Momjian wrote:
> On Wed, Apr 22, 2026 at 03:11:23AM -0400, Bruce Momjian wrote:
> > On Tue, Apr 21, 2026 at 05:17:13PM -0400, Bruce Momjian wrote:
> > > On Tue, Apr 21, 2026 at 04:18:40PM -0400, Bruce Momjian wrote:
> > > > Let me work on creating such a list and we will see how it goes.  I am
> > > > traveling now so it will be delayed.
> > > 
> > > That was easy with awk, so done and attached.  There are 1556 commits
> > > from the start of PG 19 to the AS OF date of the release notes that I
> > > did not include in the release notes.
> > 
> > Here is a better version with the "[DOC]" marker I use.
> 
> I documented how I created this "excluded commits" list as item 12 here:
> 
> 	https://wiki.postgresql.org/wiki/Creating_Major_Release_Notes

In item 2, I added a link to my MicroEmacs 4 text editor macros in case
someone needs to port those to another text editor.

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-05-07T22:01:16Z

On Mon, Apr 20, 2026 at 09:03:41PM +0800, Xuneng Zhou wrote:
> Thanks for working on the draft. Here're some comments for it:
> 
> 1) Improve performance of pgstattuple by using streaming reads
> 
> There are two related commits that improve the performance of
> pgstattuple. The current hyperlink references [1]; would it make sense
> to include [2] too?

Sure, added.

> [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=213f0079b
> [2] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=ae58189a4d523f0156ebe30f4534180555669e88
> 
> 
> 2) Additionally, would this[3] be something worth mentioning in the
> General Performance section? The improvement looks fairly big.
> 
> [3] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=6c228755add8f0714677440d53a160f9ed332902

Sure, I added it to an existing item.

> 3) Allow standbys to wait for LSN values to be replayed via WAIT FOR
> As for this feature, the follow-up commit[4] extends the WAIT FOR
> command to support waiting for flush and write operations. Is it
> helpful for users to be aware of these use cases as well?
> 
> [4] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=49a181b5d634340fcfb7c762c387c03f6405367e

Oh, that's a good point.  I missed that additional functionality.

All fixed in the attached, applied patch.

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-05-07T23:08:21Z

On Tue, Apr 21, 2026 at 05:24:59AM -0700, Etsuro Fujita wrote:
> On Wed, Apr 15, 2026 at 10:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> > I have completed the first draft of the PG 19 release notes:
> >
> >         https://www.postgresql.org/docs/devel/release-19.html
> 
> Thank you!
> 
> "Allow the retrieval of statistics from foreign data wrapper servers
> (Corey Huinker, Etsuro Fujita)"
> 
> This is mentioned in the Additional Modules section, presumably
> because it was supported in postgres_fdw, but it isn't limited to
> postgres_fdw, so we should move it to the General Performance section?

Well, the full text is:

	Allow the retrieval of statistics from foreign data wrapper servers
	(Corey Huinker, Etsuro Fujita) §

	This is enabled for postgres_fdw by using the option restore_stats. The
	default is for ANALYZE to retrieve rows from the remote server to
	locally generate statistics.

It clearly mentions in the detail that it applies only to postgres_fdw,
so I think it is already in the right section.  While it technically can
be done by any FDW, it is now only postgres_fdw so people looking for
postgres_fdw improvements will find it in the Additional Modules
section.  What we can do is to reword it to:

-->	Allow the retrieval of statistics from postgres_fdw foreign data wrapper servers
	(Corey Huinker, Etsuro Fujita) §

-->	This is enabled by using the option restore_stats. The
	default is for ANALYZE to retrieve rows from the remote server to
	locally generate statistics.

but I think this is worse because it sounds like it can _only_ ever be
done by postgres_fdw.  However, if you prefer this I will make this
change.

I avoided "General Performance" because frankly, it is only
postgres_fdw, and it not a "General" performance improvement, and we
have a section for postgres_fdw already.

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-05-08T00:20:24Z

On Wed, Apr 22, 2026 at 11:10:06AM +0800, jian he wrote:
> On Wed, Apr 15, 2026 at 9:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > I have completed the first draft of the PG 19 release notes:
> >
> >         https://www.postgresql.org/docs/devel/release-19.html
> >
> 
> Change FDW function prototypes to use uint* instead of bit* typedefs
> (Nathan Bossart) §
> This commit doesn't seem related to FDW?

Wow, I have no idea why I put FDW in there.  Next text is:

	Change function prototypes to use uint* instead of bit* typedefs (Nathan
	Bossart)

> Allow btree_gin to match partial qualifications (Tom Lane) § §
> I don't understand "partial qualifications", the commit seems more
> about "cross type operators".

Yeah, another mistake.  I got the description from this doc change in
the patch:

+       Compare a partial-match query key to an index key.
+       <literal>partial_key</literal> is a query key that was returned
+       by <function>extractQuery</function> with an indication that it
+       requires partial match, and <literal>key</literal> is an index entry.
+       Returns an integer

but that is only a clarification of an existing sentence, and I mistook
that for a new feature.  If a patch has a doc change, I tend to focus on
that, but made a mistake here.  New text is:

	Change btree_gin to support all btree-supported cross-type comparisons
	(Tom Lane)

> https://git.postgresql.org/cgit/postgresql.git/commit/?id=999f172d
> Can this also be added to the release notes?

Uh, I saw that one, and I don't normally mention changes where rare
actions used to generate errors, and don't anymore, and I saw this one
as being in that category.

> Do you think this
> (https://git.postgresql.org/cgit/postgresql.git/commit/?id=00c025a001170979e99706ce746f75fcc615761d)
> worth add to the release notes?
>
> Before commit:
> https://www.postgresql.org/docs/current/functions-matching.html#FUNCTIONS-POSIX-REGEXP
> After commit:
> https://www.postgresql.org/docs/devel/functions-matching.html#FUNCTIONS-POSIX-LIST

I saw this as a documentation restructuring, and I usually only mention
document changes that create significant new content.

Attached patch applied.

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-05-08T00:52:35Z

On Fri, May  1, 2026 at 01:24:51PM +0000, Phil Florent wrote:
> Hi,
> I see on many UTF-8 customer bases expression-based index on lower(col) to
> fulfill some ORM implementation (lower(col) = lower(exp) or "ilike" but ilike
> is even more "difficult" to index so lower(col) is not so bad...) If pg 19
> makes lower(utf-8_text) faster, it's definitely something I would be happy to
> read in a major upgrade . 

Yes, agreed.  I had not considered how impactful this would be, based on
the commit message.  Index usage sounds like a huge win.  Attached patch
applied.

---------------------------------------------------------------------------


> Best regards,
> Phil
> 
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> De : Andreas Karlsson <andreas@proxel.se>
> Envoyé : jeudi 30 avril 2026 09:16
> À : Bruce Momjian <bruce@momjian.us>; PostgreSQL-development
> <pgsql-hackers@lists.postgresql.org>
> Objet : Re: First draft of PG 19 release notes
>  
> On 4/30/26 9:08 AM, Andreas Karlsson wrote:
> > I noticed that two of my performance patches were not included in the
> > release notes and I personally think one of them belongs in the release
> > notes while other not.
> >
> > The one I think belongs is the one below since it it really results in
> > major speedups of lower(), upper(), initcap() and casefold() on ICU with
> > UTF-8. Not having to convert from UTF-8 to UTF-32 and back is often a
> > major speedup.
> 
> Saw the big discussion on performance improvements if they should be
> included or not. So I will just leave this alone. :)
> 
> --
> Andreas Karlsson
> Percona
> 
> 
> 

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-05-08T00:54:18Z

On Fri, May  1, 2026 at 10:16:24AM +0900, Richard Guo wrote:
> On Wed, Apr 15, 2026 at 10:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> > I have completed the first draft of the PG 19 release notes:
> >
> >         https://www.postgresql.org/docs/devel/release-19.html
> 
> I just committed 8d829f5a0 to fix JSON_ARRAY(subquery) to return an
> empty JSON array instead of NULL over an empty result set, per the
> SQL/JSON standard.  Since this is a user-visible behavior change, we
> need to add an item to the v19 migration section to call it out.
> 
> Suggested entry:
> 
>  - Make JSON_ARRAY(query_expression) return an empty JSON array when
>    the subquery returns no rows (Richard Guo)
> 
>    Previously, an empty result set produced NULL.  This corrects the
>    behavior to match the SQL/JSON standard.  Application code that
>    relied on the previous NULL behavior may need to be updated.

I will add this as soon as I update with the new commits.  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.

Re: First draft of PG 19 release notes

Etsuro Fujita <etsuro.fujita@gmail.com> — 2026-05-09T09:15:44Z

On Fri, May 8, 2026 at 8:08 AM Bruce Momjian <bruce@momjian.us> wrote:
> On Tue, Apr 21, 2026 at 05:24:59AM -0700, Etsuro Fujita wrote:
> > "Allow the retrieval of statistics from foreign data wrapper servers
> > (Corey Huinker, Etsuro Fujita)"
> >
> > This is mentioned in the Additional Modules section, presumably
> > because it was supported in postgres_fdw, but it isn't limited to
> > postgres_fdw, so we should move it to the General Performance section?
>
> Well, the full text is:
>
>         Allow the retrieval of statistics from foreign data wrapper servers
>         (Corey Huinker, Etsuro Fujita) §
>
>         This is enabled for postgres_fdw by using the option restore_stats. The
>         default is for ANALYZE to retrieve rows from the remote server to
>         locally generate statistics.
>
> It clearly mentions in the detail that it applies only to postgres_fdw,
> so I think it is already in the right section.  While it technically can
> be done by any FDW, it is now only postgres_fdw so people looking for
> postgres_fdw improvements will find it in the Additional Modules
> section.  What we can do is to reword it to:
>
> -->     Allow the retrieval of statistics from postgres_fdw foreign data wrapper servers
>         (Corey Huinker, Etsuro Fujita) §
>
> -->     This is enabled by using the option restore_stats. The
>         default is for ANALYZE to retrieve rows from the remote server to
>         locally generate statistics.
>
> but I think this is worse because it sounds like it can _only_ ever be
> done by postgres_fdw.  However, if you prefer this I will make this
> change.
>
> I avoided "General Performance" because frankly, it is only
> postgres_fdw, and it not a "General" performance improvement, and we
> have a section for postgres_fdw already.

Agreed.  I think the current text is fine.

Thank you for your detailed reply!

Best regards,
Etsuro Fujita

Re: First draft of PG 19 release notes

John Naylor <johncnaylorls@gmail.com> — 2026-05-11T05:40:38Z

On Wed, Apr 15, 2026 at 8:19 AM Bruce Momjian <bruce@momjian.us> wrote:

Hi Bruce, thanks for you work on this. Here are some comments:

> Allow C++ compiler mode to be used with ICU (John Naylor) §

That was just for our headerscheck and I'd be surprised if it mattered
for extension authors. Also, a later commit af2d4ca191 got rid of
including ICU headers in our local headers entirely, so that
supercedes the above anyway.

> Optionally use AVX2 CPU instructions for calculating page checksums (Matthew Sterrett, Andrew Kim) §

> Optionally use ARM Crypto Extension to Compute CRC32C (John Naylor) §

There's no option for these, the extensions are used where available.

> Improve sort performance using radix sorts (John Naylor) §

Minor quibble: I think it's more normal to refer to "sort" as a
non-count noun, when talking about a technique.

> Improve performance of numeric operations on platforms without 128-bit integer support (Dean Rasheed) §

The intent was a more of a simplification/refactoring. Server
platforms without 128-bit integer support are few and far between
(e.g. S390X on some broken versions of clang, which I tested out of
curiosity).

> Change index access method handlers to use a static IndexAmRoutines structure, rather than dynamically allocated ones (Matthias van de Meent) §
>
> This is a backwardly incompatible.

I understand this whole section to be about incompatibilities -- if
there was a follow-up mention here, it seems to have been lost along
the way.

--
John Naylor
Amazon Web Services

-- 
John Naylor
Amazon Web Services

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-05-11T21:42:34Z

On Mon, May 11, 2026 at 12:40:38PM +0700, John Naylor wrote:
> On Wed, Apr 15, 2026 at 8:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> 
> Hi Bruce, thanks for you work on this. Here are some comments:
> 
> > Allow C++ compiler mode to be used with ICU (John Naylor) §
> 
> That was just for our headerscheck and I'd be surprised if it mattered
> for extension authors. Also, a later commit af2d4ca191 got rid of
> including ICU headers in our local headers entirely, so that
> supersedes the above anyway.

Great, removed.

> > Optionally use AVX2 CPU instructions for calculating page checksums (Matthew Sterrett, Andrew Kim) §
> 
> > Optionally use ARM Crypto Extension to Compute CRC32C (John Naylor) §
> 
> There's no option for these, the extensions are used where available.

So, the "Optionally" indicates we use these instructions if the CPU
supports them.  I assume we don't use them on all CPUs.  Can you
suggest better wording?

> > Improve sort performance using radix sorts (John Naylor) §
> 
> Minor quibble: I think it's more normal to refer to "sort" as a
> non-count noun, when talking about a technique.

Done.

> > Improve performance of numeric operations on platforms without 128-bit integer support (Dean Rasheed) §
> 
> The intent was a more of a simplification/refactoring. Server
> platforms without 128-bit integer support are few and far between
> (e.g. S390X on some broken versions of clang, which I tested out of
> curiosity).

Okay, removed.

> > Change index access method handlers to use a static IndexAmRoutines structure, rather than dynamically allocated ones (Matthias van de Meent) §
> >
> > This is a backwardly incompatible.
> 
> I understand this whole section to be about incompatibilities -- if
> there was a follow-up mention here, it seems to have been lost along
> the way.

Okay, I have removed "This is a backwardly incompatible.", which I think
was your point.

-- 
  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.

Re: First draft of PG 19 release notes

Robert Treat <rob@xzilla.net> — 2026-05-12T02:34:47Z

On Mon, May 11, 2026 at 5:42 PM Bruce Momjian <bruce@momjian.us> wrote:
> On Mon, May 11, 2026 at 12:40:38PM +0700, John Naylor wrote:
> > On Wed, Apr 15, 2026 at 8:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > Hi Bruce, thanks for you work on this. Here are some comments:
> >
<snip>
> > > Optionally use AVX2 CPU instructions for calculating page checksums (Matthew Sterrett, Andrew Kim) §
> >
> > > Optionally use ARM Crypto Extension to Compute CRC32C (John Naylor) §
> >
> > There's no option for these, the extensions are used where available.
>
> So, the "Optionally" indicates we use these instructions if the CPU
> supports them.  I assume we don't use them on all CPUs.  Can you
> suggest better wording?
>

I think the simplest change would be to replace "optionally" with
"when available", although ISTR we use wording along the lines of "Add
support for" or "is now supported" when runtime/compiler checks are
involved.

Robert Treat
https://xzilla.net

Re: First draft of PG 19 release notes

John Naylor <johncnaylorls@gmail.com> — 2026-05-12T03:38:40Z

On Tue, May 12, 2026 at 9:35 AM Robert Treat <rob@xzilla.net> wrote:
>
> On Mon, May 11, 2026 at 5:42 PM Bruce Momjian <bruce@momjian.us> wrote:
> > On Mon, May 11, 2026 at 12:40:38PM +0700, John Naylor wrote:
> > > > Optionally use AVX2 CPU instructions for calculating page checksums (Matthew Sterrett, Andrew Kim) §
> > >
> > > > Optionally use ARM Crypto Extension to Compute CRC32C (John Naylor) §
> > >
> > > There's no option for these, the extensions are used where available.
> >
> > So, the "Optionally" indicates we use these instructions if the CPU
> > supports them.  I assume we don't use them on all CPUs.  Can you
> > suggest better wording?
> >
>
> I think the simplest change would be to replace "optionally" with
> "when available", although ISTR we use wording along the lines of "Add
> support for" or "is now supported" when runtime/compiler checks are
> involved.

That would be fine. The v17 and v18 release notes didn't have such
qualifying language, for things that are less common than the above
(SVE, AVX-512), but whatever.

-- 
John Naylor
Amazon Web Services

Re: First draft of PG 19 release notes

jian he <jian.universality@gmail.com> — 2026-05-12T04:11:16Z

On Wed, Apr 15, 2026 at 9:19 AM Bruce Momjian <bruce@momjian.us> wrote:
>
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html
>

Add hooks planner_setup_hook and planner_shutdown_hook (Robert Haas) §

https://git.postgresql.org/cgit/postgresql.git/commit/?id=4020b37
We also introduced join_path_setup_hook, joinrel_setup_hook.

Should we also mention these two hooks?

Re: First draft of PG 19 release notes

Greg Sabino Mullane <htamfids@gmail.com> — 2026-05-12T12:41:28Z

I can kind of understand why this did not make the cut:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=41d69e6d

(Add labels to help make psql's hidden queries more understandable)

... but I'm in favor (yes, somewhat selfishly to be honest) of listing all
changes, no matter how small. Is there a written criteria or guidelines for
these things? I think the bar is already low if we list things like
"improved tab completion", TBH.

Re: First draft of PG 19 release notes

Melanie Plageman <melanieplageman@gmail.com> — 2026-05-12T14:57:57Z

On Tue, May 12, 2026 at 8:42 AM Greg Sabino Mullane <htamfids@gmail.com> wrote:
>
> I can kind of understand why this did not make the cut:
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=41d69e6d
>
> (Add labels to help make psql's hidden queries more understandable)
>
> ... but I'm in favor (yes, somewhat selfishly to be honest) of listing all changes, no matter how small. Is there a written criteria or guidelines for these things? I think the bar is already low if we list things like "improved tab completion", TBH.

I agree that it is hard to know when advocating for our own features
makes sense on this thread. When another feature makes the list that
seems to have a less compelling case, it is tempting to jump in again.
But then, how do we know we are being objective and doing what is in
the best interest of the user reading the release notes?

For example, I upthread [1] suggested that users may want to know that
different WAL records would be produced because we've eliminated one
and incorporated their contents into another. While it is a
performance improvement, I mainly suggested it because an advanced
user examining WAL may be confused. Bruce noted that this was too
internal. I can see his point. But there are other things mentioned
that are as internal or more so. But arguing makes me feel like I'm
doing self-promotion. I've transitioned to only bringing up things
that I did that seem like they would be confusing to the user and they
would go to the release notes to check for, as opposed to bringing up
performance improvements.

However, for performance improvements, at some point the bar was
something that would encourage people to go through the effort of
upgrading to the latest version to get those improvements or to
migrate to Postgres when they previously may not have because a
performance related thing was holding them back. Things like improved
tab completion are probably not this kind of tipping point, so I think
that isn't the threshold anymore.

I would be interested in seeing a summary of where we landed in terms
of criteria for what should be in the release notes on this thread,
since it is split across many emails. I get the sense that we've
shifted it a bit based on discussion in this thread, and I can't quite
grasp the specifics. And people who replied early on but not after the
discussion led to changes may not be paying attention to the thread
anymore.

- Melanie

[1] https://www.postgresql.org/message-id/ad_6RBwUlRooQK-9%40momjian.us

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-05-12T19:11:16Z

On Tue, May 12, 2026 at 10:38:40AM +0700, John Naylor wrote:
> On Tue, May 12, 2026 at 9:35 AM Robert Treat <rob@xzilla.net> wrote:
> >
> > On Mon, May 11, 2026 at 5:42 PM Bruce Momjian <bruce@momjian.us> wrote:
> > > On Mon, May 11, 2026 at 12:40:38PM +0700, John Naylor wrote:
> > > > > Optionally use AVX2 CPU instructions for calculating page checksums (Matthew Sterrett, Andrew Kim) §
> > > >
> > > > > Optionally use ARM Crypto Extension to Compute CRC32C (John Naylor) §
> > > >
> > > > There's no option for these, the extensions are used where available.
> > >
> > > So, the "Optionally" indicates we use these instructions if the CPU
> > > supports them.  I assume we don't use them on all CPUs.  Can you
> > > suggest better wording?
> > >
> >
> > I think the simplest change would be to replace "optionally" with
> > "when available", although ISTR we use wording along the lines of "Add
> > support for" or "is now supported" when runtime/compiler checks are
> > involved.
> 
> That would be fine. The v17 and v18 release notes didn't have such
> qualifying language, for things that are less common than the above
> (SVE, AVX-512), but whatever.

Okay, I will just remove the "Optionally" and see if anyone complains.
Patch attached and applied.

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-05-12T20:15:22Z

On Tue, May 12, 2026 at 12:11:16PM +0800, jian he wrote:
> On Wed, Apr 15, 2026 at 9:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > I have completed the first draft of the PG 19 release notes:
> >
> >         https://www.postgresql.org/docs/devel/release-19.html
> >
> 
> Add hooks planner_setup_hook and planner_shutdown_hook (Robert Haas) §
> 
> https://git.postgresql.org/cgit/postgresql.git/commit/?id=4020b37
> We also introduced join_path_setup_hook, joinrel_setup_hook.
> 
> Should we also mention these two hooks?

Yes, I missed seeing the addition of these two hooks, so patch attached
and applied.

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-05-12T20:27:55Z

On Tue, May 12, 2026 at 08:41:28AM -0400, Greg Sabino Mullane wrote:
> I can kind of understand why this did not make the cut:
> 
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=41d69e6d
> 
> (Add labels to help make psql's hidden queries more understandable)
> 
> ... but I'm in favor (yes, somewhat selfishly to be honest) of listing all
> changes, no matter how small. Is there a written criteria or guidelines for
> these things? I think the bar is already low if we list things like "improved
> tab completion", TBH.

I am not sure how to answer this except to say that I try to list items
that are important for the general reading audience to know.  All
changes are already in the git commit log.

If you would like to make the case that listing all changes would be
helpful for the general reading audience, please make that case.  If you
would like to make the case that being most helpful for the general
reading audience is not the right goal, please explain.

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-05-12T20:31:42Z

On Tue, May 12, 2026 at 10:57:57AM -0400, Melanie Plageman wrote:
> I would be interested in seeing a summary of where we landed in terms
> of criteria for what should be in the release notes on this thread,
> since it is split across many emails. I get the sense that we've
> shifted it a bit based on discussion in this thread, and I can't quite
> grasp the specifics. And people who replied early on but not after the
> discussion led to changes may not be paying attention to the thread
> anymore.

If multiple people suggest a change, it is probably the right thing to
do so I do it.  I have posted a list of everything I excluded, so that
could be used to analyze what was missing.  I do miscategorize items
every time I do this, so I expect such adjustments.  If the general
readers report that something is missing or wrong, it means I made a
serious mistake and none of this review process caught it --- it has
happened a few times over the years.

-- 
  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.

Re: First draft of PG 19 release notes

Peter Geoghegan <pg@bowt.ie> — 2026-05-15T16:31:59Z

On Tue, Apr 14, 2026 at 9:19 PM Bruce Momjian <bruce@momjian.us> wrote:
> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html

I do not think that this item merits mention in the release notes:

"Add fake LSN support to hash index AM (Peter Geoghegan)"

It offers no user-visible benefit. It's just preparation for index
prefetching, which didn't make it into Postgres 19.

-- 
Peter Geoghegan

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-05-15T17:27:40Z

On Fri, May 15, 2026 at 12:31:59PM -0400, Peter Geoghegan wrote:
> On Tue, Apr 14, 2026 at 9:19 PM Bruce Momjian <bruce@momjian.us> wrote:
> > I have completed the first draft of the PG 19 release notes:
> >
> >         https://www.postgresql.org/docs/devel/release-19.html
> 
> I do not think that this item merits mention in the release notes:
> 
> "Add fake LSN support to hash index AM (Peter Geoghegan)"
> 
> It offers no user-visible benefit. It's just preparation for index
> prefetching, which didn't make it into Postgres 19.

Ah, I see your point, and the commit message was clear:

    This commit is similar to commit 8a879119, which taught nbtree to
    use fake LSNs to improve its dropPin behavior.  However, unlike that
    commit, this is not an independently useful enhancement, since hash
    doesn't implement anything like nbtree's dropPin behavior (not yet).

Item removed.

-- 
  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.

Re: First draft of PG 19 release notes

Chao Li <li.evan.chao@gmail.com> — 2026-05-26T05:25:15Z


> On May 16, 2026, at 01:27, Bruce Momjian <bruce@momjian.us> wrote:
> 
> On Fri, May 15, 2026 at 12:31:59PM -0400, Peter Geoghegan wrote:
>> On Tue, Apr 14, 2026 at 9:19 PM Bruce Momjian <bruce@momjian.us> wrote:
>>> I have completed the first draft of the PG 19 release notes:
>>> 
>>>        https://www.postgresql.org/docs/devel/release-19.html
>> 
>> I do not think that this item merits mention in the release notes:
>> 
>> "Add fake LSN support to hash index AM (Peter Geoghegan)"
>> 
>> It offers no user-visible benefit. It's just preparation for index
>> prefetching, which didn't make it into Postgres 19.
> 
> Ah, I see your point, and the commit message was clear:
> 
>    This commit is similar to commit 8a879119, which taught nbtree to
>    use fake LSNs to improve its dropPin behavior.  However, unlike that
>    commit, this is not an independently useful enhancement, since hash
>    doesn't implement anything like nbtree's dropPin behavior (not yet).
> 
> Item removed.
> 
> -- 
>  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.
> 
> 

Chong Peng, whom I added to CC, reported this release note issue to me, so I’m just forwarding the message:

```
<listitem>
<para>
Add slot synchronization skip information to pg_stat_replication_slots (Shlok Kyal)
<ulink url="&commit_baseurl;76b78721c">&sect;</ulink>
<ulink url="&commit_baseurl;e68b6adad">&sect;</ulink>
<ulink url="&commit_baseurl;5db6a344a">&sect;</ulink>
</para>

<para>
The new columns are slotsync_skip_count, slotsync_last_skip, and slotsync_skip_reason.
</para>
</listitem>
```

The feature description is inaccurate: slotsync_skip_count and slotsync_last_skip belong to pg_stat_replication_slots, while slotsync_skip_reason belongs to pg_replication_slots. Maybe it could be reworded as:
```
Add slot synchronization skip information to pg_stat_replication_slots and pg_replication_slots (Shlok Kyal)
```

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-05-26T15:00:21Z

On Tue, May 26, 2026 at 01:25:15PM +0800, Chao Li wrote:
> Chong Peng, whom I added to CC, reported this release note issue to me, so I’m just forwarding the message:
> 
> ```
> <listitem>
> <para>
> Add slot synchronization skip information to pg_stat_replication_slots (Shlok Kyal)
> <ulink url="&commit_baseurl;76b78721c">&sect;</ulink>
> <ulink url="&commit_baseurl;e68b6adad">&sect;</ulink>
> <ulink url="&commit_baseurl;5db6a344a">&sect;</ulink>
> </para>
> 
> <para>
> The new columns are slotsync_skip_count, slotsync_last_skip, and slotsync_skip_reason.
> </para>
> </listitem>
> ```
> 
> The feature description is inaccurate: slotsync_skip_count and slotsync_last_skip belong to pg_stat_replication_slots, while slotsync_skip_reason belongs to pg_replication_slots. Maybe it could be reworded as:
> ```
> Add slot synchronization skip information to pg_stat_replication_slots and pg_replication_slots (Shlok Kyal)
> ```

Yes, very good point.  I missed that detail when merging the commit
items.  I fixed it as you suggested, patch attached.

-- 
  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.

Re: First draft of PG 19 release notes

Thom Brown <thom@linux.com> — 2026-05-26T15:46:12Z

On Tue, 26 May 2026 at 16:00, Bruce Momjian <bruce@momjian.us> wrote:
>
> On Tue, May 26, 2026 at 01:25:15PM +0800, Chao Li wrote:
> > Chong Peng, whom I added to CC, reported this release note issue to me, so I’m just forwarding the message:
> >
> > ```
> > <listitem>
> > <para>
> > Add slot synchronization skip information to pg_stat_replication_slots (Shlok Kyal)
> > <ulink url="&commit_baseurl;76b78721c">&sect;</ulink>
> > <ulink url="&commit_baseurl;e68b6adad">&sect;</ulink>
> > <ulink url="&commit_baseurl;5db6a344a">&sect;</ulink>
> > </para>
> >
> > <para>
> > The new columns are slotsync_skip_count, slotsync_last_skip, and slotsync_skip_reason.
> > </para>
> > </listitem>
> > ```
> >
> > The feature description is inaccurate: slotsync_skip_count and slotsync_last_skip belong to pg_stat_replication_slots, while slotsync_skip_reason belongs to pg_replication_slots. Maybe it could be reworded as:
> > ```
> > Add slot synchronization skip information to pg_stat_replication_slots and pg_replication_slots (Shlok Kyal)
> > ```
>
> Yes, very good point.  I missed that detail when merging the commit
> items.  I fixed it as you suggested, patch attached.
>
> --
>   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.

Did a review and found a few issues. Attached fixes.

Regards

Thom

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-05-26T20:32:47Z

On Tue, May 26, 2026 at 04:46:12PM +0100, Thom Brown wrote:
> On Tue, 26 May 2026 at 16:00, Bruce Momjian <bruce@momjian.us> wrote:
> Did a review and found a few issues. Attached fixes.

Oh, all very good, applied, 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.

Re: First draft of PG 19 release notes

Thom Brown <thom@linux.com> — 2026-05-26T21:14:32Z

On Tue, 26 May 2026 at 21:33, Bruce Momjian <bruce@momjian.us> wrote:
>
> On Tue, May 26, 2026 at 04:46:12PM +0100, Thom Brown wrote:
> > On Tue, 26 May 2026 at 16:00, Bruce Momjian <bruce@momjian.us> wrote:
> > Did a review and found a few issues. Attached fixes.
>
> Oh, all very good, applied, thanks.

I've just spotted that this was a slightly older version of the patch
I had accidentally selected. Attached are the missing changes I had
intended to also send.

Regards

Thom

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-05-26T21:49:54Z

On Tue, May 26, 2026 at 10:14:32PM +0100, Thom Brown wrote:
> On Tue, 26 May 2026 at 21:33, Bruce Momjian <bruce@momjian.us> wrote:
> >
> > On Tue, May 26, 2026 at 04:46:12PM +0100, Thom Brown wrote:
> > > On Tue, 26 May 2026 at 16:00, Bruce Momjian <bruce@momjian.us> wrote:
> > > Did a review and found a few issues. Attached fixes.
> >
> > Oh, all very good, applied, thanks.
> 
> I've just spotted that this was a slightly older version of the patch
> I had accidentally selected. Attached are the missing changes I had
> intended to also send.

Wow, thanks for the additional fixes, applied.

-- 
  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.

Re: First draft of PG 19 release notes

Yugo Nagata <nagata@sraoss.co.jp> — 2026-06-05T08:11:08Z

Hi,

On Tue, 14 Apr 2026 21:18:57 -0400
Bruce Momjian <bruce@momjian.us> wrote:

> I have completed the first draft of the PG 19 release notes:
> 
> 	https://www.postgresql.org/docs/devel/release-19.html

I noticed duplicate names in the psql tab completion improvement entry.
Yugo Nagata and Fujii Masao each appear twice.

If this is not intentional, we could remove the duplicates as in the attached patch.

Regareds,
Yugo Nagata

-- 
Yugo Nagata <nagata@sraoss.co.jp>

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-06-05T13:55:27Z

On Fri, Jun  5, 2026 at 05:11:08PM +0900, Yugo Nagata wrote:
> Hi,
> 
> On Tue, 14 Apr 2026 21:18:57 -0400
> Bruce Momjian <bruce@momjian.us> wrote:
> 
> > I have completed the first draft of the PG 19 release notes:
> > 
> > 	https://www.postgresql.org/docs/devel/release-19.html
> 
> I noticed duplicate names in the psql tab completion improvement entry.
> Yugo Nagata and Fujii Masao each appear twice.
> 
> If this is not intentional, we could remove the duplicates as in the attached patch.

Yes, my mistake, will fix, 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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-06-05T18:14:21Z

On Fri, Jun  5, 2026 at 09:55:27AM -0400, Bruce Momjian wrote:
> On Fri, Jun  5, 2026 at 05:11:08PM +0900, Yugo Nagata wrote:
> > Hi,
> > 
> > On Tue, 14 Apr 2026 21:18:57 -0400
> > Bruce Momjian <bruce@momjian.us> wrote:
> > 
> > > I have completed the first draft of the PG 19 release notes:
> > > 
> > > 	https://www.postgresql.org/docs/devel/release-19.html
> > 
> > I noticed duplicate names in the psql tab completion improvement entry.
> > Yugo Nagata and Fujii Masao each appear twice.
> > 
> > If this is not intentional, we could remove the duplicates as in the attached patch.
> 
> Yes, my mistake, will fix, thanks.

I want to thank everyone for the fixes/improvements they have supplied
for the PG 19 release notes.  I am now satisfied with them and I think
they are close to what they will look link for PG 19 final. Here are the
current contents:

	https://www.postgresql.org/docs/19/release-19.html

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-06-05T18:58:41Z

On Fri, Jun  5, 2026 at 02:14:21PM -0400, Bruce Momjian wrote:
> On Fri, Jun  5, 2026 at 09:55:27AM -0400, Bruce Momjian wrote:
> > On Fri, Jun  5, 2026 at 05:11:08PM +0900, Yugo Nagata wrote:
> > > Hi,
> > > 
> > > On Tue, 14 Apr 2026 21:18:57 -0400
> > > Bruce Momjian <bruce@momjian.us> wrote:
> > > 
> > > > I have completed the first draft of the PG 19 release notes:
> > > > 
> > > > 	https://www.postgresql.org/docs/devel/release-19.html
> > > 
> > > I noticed duplicate names in the psql tab completion improvement entry.
> > > Yugo Nagata and Fujii Masao each appear twice.
> > > 
> > > If this is not intentional, we could remove the duplicates as in the attached patch.
> > 
> > Yes, my mistake, will fix, thanks.
> 
> I want to thank everyone for the fixes/improvements they have supplied
> for the PG 19 release notes.  I am now satisfied with them and I think
> they are close to what they will look link for PG 19 final. Here are the
> current contents:
> 
> 	https://www.postgresql.org/docs/19/release-19.html

My apologies, this is the old version;  the most current version is
here:

	https://momjian.us/pgsql_docs/release-19.html

-- 
  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.

Re: First draft of PG 19 release notes

Baji Shaik <baji.pgdev@gmail.com> — 2026-06-05T19:17:01Z

On Fri, Jun 5, 2026 at 1:58 PM Bruce Momjian <bruce@momjian.us> wrote:

> My apologies, this is the old version;  the most current version is
> here:
>
>         https://momjian.us/pgsql_docs/release-19.html

Can e5035950dab ("psql: Fix tab completion for REPACK boolean options")
also be part of the notes?
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=e5035950dab

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-06-05T19:29:17Z

On Fri, Jun  5, 2026 at 02:17:01PM -0500, Baji Shaik wrote:
> 
> 
> On Fri, Jun 5, 2026 at 1:58 PM Bruce Momjian <bruce@momjian.us> wrote:
> 
>     My apologies, this is the old version;  the most current version is
>     here:
> 
>             https://momjian.us/pgsql_docs/release-19.html
> 
> 
> Can e5035950dab ("psql: Fix tab completion for REPACK boolean options")
> also be part of the notes?
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=e5035950dab

Uh, I don't add tab fixes for new commands in the release note.  I am
more focused on adding changes for tab completion for existing commands,
though I tend to add them on the first pass but not in later months.

-- 
  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.

Re: First draft of PG 19 release notes

Álvaro Herrera <alvherre@kurilemu.de> — 2026-06-06T13:08:05Z

On 2026-Jun-05, Bruce Momjian wrote:

> > I want to thank everyone for the fixes/improvements they have supplied
> > for the PG 19 release notes. I am now satisfied with them and I think
> > they are close to what they will look link for PG 19 final. Here are the
> > current contents:

> https://momjian.us/pgsql_docs/release-19.html

Thanks for putting these together! I have a few comments:

* In the incompatibilities section, we have
- Prevent carriage returns and line feeds in database, role, and
tablespace names

This was changed to avoid security problems. pg_upgrade will also
disallow upgrading of clusters that use such names.

The verb "prevent" here is a bit strange; I think "reject" would be
better. Also, I think the phrase involving pg_upgrade should come
before the reason for the change.

We also have this item:

Change the default index opclasses for inet and cidr data types from
btree_gist to GiST

The btree_gist inet/cidr opclasses are broken because they can exclude
rows that should be returned. pg_upgrade will fail to upgrade if
btree_gist inet/cidr indexes exist in the old server.

Why do we say "pg_upgrade will fail to upgrade" here instead of the
(IMO better) wording in the previous item? That is, "pg_upgrade will
disallow upgrading if btree_gist inet/cidr indexes exist in the old
server". The current wording of "fail to" suggest that this is a
pg_upgrade shortcoming, which it isn't.

* In section E.1.3.1.1 Optimizer, I think the item
"Allow extended statistics on virtual generated columns"
should come before all other items, because it's the only one that
requires user action in order for them to take advantage of it. All
the other items refer to some optimization that occurs automatically.

* Section E.1.3.1.2 General Performance, the item
Allow autovacuum to use parallel vacuum workers
lacks a link to
https://momjian.us/pgsql_docs/sql-createtable.html#RELOPTION-AUTOVACUUM-PARALLEL-WORKERS

* Section E.1.3.1.3 System Views, the two items
Add vacuum initiation details to system view pg_stat_progress_vacuum
Add analyze initiation details to system view pg_stat_progress_analyze
Maybe they should be a single entry?
Add vacuum and analyze initiation details to system view
pg_stat_progress_vacuum and pg_stat_progress_analyze respectively
(Not really sure about this one)

* E.1.3.1.4 Monitoring
Add server variable log_autoanalyze_min_duration to log long-running
autoanalyze operations (Shinya Kato) §
Server variable log_autovacuum_min_duration now only controls logging
of autovacuum operations.

I think it's confusing to talk about "autoanalyze" as if it were
an action taken by an agent other than autovacuum. I mean, we have
autovacuum which runs autovacuums and also autovacuum which runs
autoanalyzes? To my mind that makes no sense -- I think we have one
autovacuum, which runs vacuum and analyze.

I would explain this as
Add server variable log_autoanalyze_min_duration to log long-running
analyze operations run by autovacuum (Shinya Kato) §
Server variable log_autovacuum_min_duration now only controls logging
of vacuum operations run by autovacuum.

* Add WAL full-page write bytes reporting to VACUUM and ANALYZE logging
(Shinya Kato) §
Maybe this should be "Report bytes of full-page WAL writes to VACUUM
and ANALYZE logging".
(This also appears in E.1.3.3.3 EXPLAIN and E.1.3.1.3 System Views)

* Add function pg_get_multixact_stats() to report multixact activity
(Naga Appani) §
I think this item should appear second in the section, right after the
one for log_min_messages, on importance grounds.

* Two entries make the acronym LSN point to
https://momjian.us/pgsql_docs/wal-internals.html
I think a better target is the glossary item
https://momjian.us/pgsql_docs/glossary.html#GLOSSARY-LOG-SEQUENCE-NUMBER
The shorter definition in the glossary is possibly more useful for a
release note reader; and if they want even more detail, the glossary
definition does point to the WAL internals.
A third entry appears in E.1.3.1.6

* E.1.3.1.5 Server Configuration
* Allow online enabling and disabling of data checksums
Previously the checksum status could only be set at initialization and
changed only while the cluster was offline using pg_checksums.

The word "only" appears twice in the second phrase, which is awkward.
Maybe reword it as
Previously the checksum status would be fixed at initialization time and
only changed while the cluster was offline usiNG PG_checksums.

* Add scoring system to control the order that tables are autovacuumed
I think using "autovacuumed" as a verb is terrible grammar. I would
rather have "... are processed by autovacuum".

* Allow background workers to be configured to terminate before
database-level operations (Aya Iwata) §
This sounds far too mysterious; it probably warrants more detail.
Also, move it a bit upwards: just below SNI perhaps? (That isn't
much, but all the other items in this section also look valuable.)

* E.1.3.3.2 Copy
* Allow COPY TO to output partitioned tables (Jian He, Ajin Cherian) § §
"to output partitioned tables"? This reads really awkward.
What about ... "Allow partitioned tables to be [processed / read] by
COPY TO directly" or something like that?

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"La vida es para el que se aventura"

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-06-08T03:43:16Z

On Sat, Jun  6, 2026 at 03:08:05PM +0200, Álvaro Herrera wrote:
> On 2026-Jun-05, Bruce Momjian wrote:
> 
> > > I want to thank everyone for the fixes/improvements they have supplied
> > > for the PG 19 release notes.  I am now satisfied with them and I think
> > > they are close to what they will look link for PG 19 final. Here are the
> > > current contents:
> 
> > 	https://momjian.us/pgsql_docs/release-19.html
> 
> Thanks for putting these together!  I have a few comments:
> 
> * In the incompatibilities section, we have
>   - Prevent carriage returns and line feeds in database, role, and
>   tablespace names
> 
>   This was changed to avoid security problems. pg_upgrade will also
>   disallow upgrading of clusters that use such names.
> 
>   The verb "prevent" here is a bit strange; I think "reject" would be
>   better.  Also, I think the phrase involving pg_upgrade should come
>   before the reason for the change.

Agreed.  I went with "Disallow carriage returns and line feeds", and I
moved the security text to the end as you suggested.

> 
>   We also have this item:
> 
>   Change the default index opclasses for inet and cidr data types from
>   btree_gist to GiST
> 
>   The btree_gist inet/cidr opclasses are broken because they can exclude
>   rows that should be returned. pg_upgrade will fail to upgrade if
>   btree_gist inet/cidr indexes exist in the old server.
> 
>   Why do we say "pg_upgrade will fail to upgrade" here instead of the
>   (IMO better) wording in the previous item?  That is, "pg_upgrade will
>   disallow upgrading if btree_gist inet/cidr indexes exist in the old
>   server".  The current wording of "fail to" suggest that this is a
>   pg_upgrade shortcoming, which it isn't.

I went with similar wording "pg_upgrade will disallow upgrading".

> * In section E.1.3.1.1 Optimizer, I think the item
>   "Allow extended statistics on virtual generated columns"
>   should come before all other items, because it's the only one that
>   requires user action in order for them to take advantage of it.  All
>   the other items refer to some optimization that occurs automatically.

While the first item in each section is the most important, I then list
later items in groups that have similar characteristics, which I think
simplifies reading.  While I could order all items in importance order,
I think it would be much more confusing to read.  Right now the item you
mention is in a group of items about optimizer statistics.

> * Section E.1.3.1.2 General Performance, the item
>   Allow autovacuum to use parallel vacuum workers
>   lacks a link to
>   https://momjian.us/pgsql_docs/sql-createtable.html#RELOPTION-AUTOVACUUM-PARALLEL-WORKERS

Added link.

> * Section E.1.3.1.3 System Views, the two items
>   Add vacuum initiation details to system view pg_stat_progress_vacuum
>   Add analyze initiation details to system view pg_stat_progress_analyze
>   Maybe they should be a single entry?
>   Add vacuum and analyze initiation details to system view
>   pg_stat_progress_vacuum and pg_stat_progress_analyze respectively
>   (Not really sure about this one)

I looked at merging these before, and the existence of the "mode" column
in vacuum but not analyze made the merged item too complicated to
understand.

> * E.1.3.1.4 Monitoring
>   Add server variable log_autoanalyze_min_duration to log long-running
>   autoanalyze operations (Shinya Kato) §
>   Server variable log_autovacuum_min_duration now only controls logging
>   of autovacuum operations.
> 
>   I think it's confusing to talk about "autoanalyze" as if it were
>   an action taken by an agent other than autovacuum.  I mean, we have
>   autovacuum which runs autovacuums and also autovacuum which runs
>   autoanalyzes?  To my mind that makes no sense -- I think we have one
>   autovacuum, which runs vacuum and analyze.
> 
>   I would explain this as
>   Add server variable log_autoanalyze_min_duration to log long-running
>   analyze operations run by autovacuum (Shinya Kato) §
>   Server variable log_autovacuum_min_duration now only controls logging
>   of vacuum operations run by autovacuum.

Well, the column calls it autoanalyze, but I agree when we are talking
about the tool, autovacuum is better, so changed.

>   * Add WAL full-page write bytes reporting to VACUUM and ANALYZE logging
>   (Shinya Kato) §
>   Maybe this should be "Report bytes of full-page WAL writes to VACUUM
>   and ANALYZE logging".
>   (This also appears in E.1.3.3.3 EXPLAIN and E.1.3.1.3 System Views)

Yes, saying "Add reporting of X" is better than "add X reporting";  fixed
in both cases.

>   * Add function pg_get_multixact_stats() to report multixact activity
>   (Naga Appani) §
>   I think this item should appear second in the section, right after the
>   one for log_min_messages, on importance grounds.

Again, already grouped in a section about monitoring functions, and I do
think the earlier items are more important.

>   * Two entries make the acronym LSN point to 
>   https://momjian.us/pgsql_docs/wal-internals.html
>   I think a better target is the glossary item
>   https://momjian.us/pgsql_docs/glossary.html#GLOSSARY-LOG-SEQUENCE-NUMBER
>   The shorter definition in the glossary is possibly more useful for a
>   release note reader; and if they want even more detail, the glossary
>   definition does point to the WAL internals.
>   A third entry appears in E.1.3.1.6

Well, the second paragraph does explain LSN so I think pointing them to
a glossary makes things worse.

> * E.1.3.1.5 Server Configuration
>   * Allow online enabling and disabling of data checksums
>   Previously the checksum status could only be set at initialization and
>   changed only while the cluster was offline using pg_checksums.
> 
>   The word "only" appears twice in the second phrase, which is awkward.
>   Maybe reword it as
>   Previously the checksum status would be fixed at initialization time and
>   only changed while the cluster was offline usiNG PG_checksums.

Yes, and the bigger problem is that there is no need to mention
initialization setting of checksums, so the first part of the sentence
is now gone.

>   * Add scoring system to control the order that tables are autovacuumed
>   I think using "autovacuumed" as a verb is terrible grammar.  I would
>   rather have "... are processed by autovacuum".

Yes, agreed, fixed.

>   * Allow background workers to be configured to terminate before
>   database-level operations (Aya Iwata) §
>   This sounds far too mysterious; it probably warrants more detail.
>   Also, move it a bit upwards: just below SNI perhaps?  (That isn't
>   much, but all the other items in this section also look valuable.)

Agreed.  I added a sentence to explain its purpose.

> * E.1.3.3.2 Copy
>   * Allow COPY TO to output partitioned tables (Jian He, Ajin Cherian) § §
>   "to output partitioned tables"?  This reads really awkward.
>   What about ... "Allow partitioned tables to be [processed / read] by
>   COPY TO directly" or something like that?

Yes, I used "process".  New output here:

	https://momjian.us/pgsql_docs/release-19.html

You certainly found some confusing items and I like the new output.

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-06-08T14:13:33Z

On Sun, Jun  7, 2026 at 11:43:16PM -0400, Bruce Momjian wrote:
> > * In section E.1.3.1.1 Optimizer, I think the item
> >   "Allow extended statistics on virtual generated columns"
> >   should come before all other items, because it's the only one that
> >   requires user action in order for them to take advantage of it.  All
> >   the other items refer to some optimization that occurs automatically.
> 
> While the first item in each section is the most important, I then list
> later items in groups that have similar characteristics, which I think
> simplifies reading.  While I could order all items in importance order,
> I think it would be much more confusing to read.  Right now the item you
> mention is in a group of items about optimizer statistics.

Actually, if there is no "most important" item in a section, I just
order by placing the largest group of similar items first.  Here are the
detais:

	https://wiki.postgresql.org/wiki/Creating_Major_Release_Notes
	order inside of sections
	               most important item first in section
	                  if none, then largest group first
	               group similar items together
	               order group by item importance
	               ideally the last item in a group will relate to the first item in the next group

-- 
  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.

Re: First draft of PG 19 release notes

Chao Li <li.evan.chao@gmail.com> — 2026-06-09T06:59:17Z


> On Jun 8, 2026, at 22:13, Bruce Momjian <bruce@momjian.us> wrote:
> 
> On Sun, Jun  7, 2026 at 11:43:16PM -0400, Bruce Momjian wrote:
>>> * In section E.1.3.1.1 Optimizer, I think the item
>>>  "Allow extended statistics on virtual generated columns"
>>>  should come before all other items, because it's the only one that
>>>  requires user action in order for them to take advantage of it.  All
>>>  the other items refer to some optimization that occurs automatically.
>> 
>> While the first item in each section is the most important, I then list
>> later items in groups that have similar characteristics, which I think
>> simplifies reading.  While I could order all items in importance order,
>> I think it would be much more confusing to read.  Right now the item you
>> mention is in a group of items about optimizer statistics.
> 
> Actually, if there is no "most important" item in a section, I just
> order by placing the largest group of similar items first.  Here are the
> detais:
> 
> https://wiki.postgresql.org/wiki/Creating_Major_Release_Notes
> order inside of sections
>               most important item first in section
>                  if none, then largest group first
>               group similar items together
>               order group by item importance
>               ideally the last item in a group will relate to the first item in the next group
> 
> -- 
>  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.
> 
> 

Hi Bruce,

This feature has been reverted by a0354e29c41a9fb7491b3c7c23f079b1923c045a.

```
<!--
Author: Andrew Dunstan <andrew@dunslane.net>
2026-03-12 [a0b6ef29a] Enable fast default for domains with non-volatile constr
-->

<listitem>
<para>
Allow the <link linkend="sql-altertable">addition of columns</link> based on domains containing constraints to usually avoid a table rewrite (Jian He)
<ulink url="&commit_baseurl;a0b6ef29a">&sect;</ulink>
</para>

<para>
Previously this always required a table rewrite.
</para>
</listitem>
```

So this item can be removed from the release note.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

Re: First draft of PG 19 release notes

Srinath Reddy Sadipiralla <srinath2133@gmail.com> — 2026-06-11T09:01:38Z

Hi Bruce,

On Wed, Apr 15, 2026 at 6:49 AM Bruce Momjian <bruce@momjian.us> wrote:

> I have completed the first draft of the PG 19 release notes:
>
>         https://www.postgresql.org/docs/devel/release-19.html

Thanks for working on this.

I noticed the notes don't mention the pg_rewind improvement committed in
5173bfd0 ("pg_rewind: Skip copy of WAL segments generated before point of
divergence") [0].

[0] -
https://www.postgresql.org/message-id/flat/181b4c6fa9c.b8b725681941212.7547232617810891479%40viggy28.dev

-- 
Thanks :)
Srinath Reddy Sadipiralla
EDB: https://www.enterprisedb.com/

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-06-16T18:14:35Z

On Tue, Jun  9, 2026 at 02:59:17PM +0800, Chao Li wrote:
> This feature has been reverted by a0354e29c41a9fb7491b3c7c23f079b1923c045a.
> 
> ```
> <!--
> Author: Andrew Dunstan <andrew@dunslane.net>
> 2026-03-12 [a0b6ef29a] Enable fast default for domains with non-volatile constr
> -->
> 
> <listitem>
> <para>
> Allow the <link linkend="sql-altertable">addition of columns</link> based on domains containing constraints to usually avoid a table rewrite (Jian He)
> <ulink url="&commit_baseurl;a0b6ef29a">&sect;</ulink>
> </para>
> 
> <para>
> Previously this always required a table rewrite.
> </para>
> </listitem>
> ```
> 
> So this item can be removed from the release note.

Thanks.  Reading the revert commit message, I am not sure I would have
associated it with this release note item's visible text.  Thanks.  I
updated the release notes to current.

-- 
  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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-06-16T23:41:23Z

On Thu, Jun 11, 2026 at 02:31:38PM +0530, Srinath Reddy Sadipiralla wrote:
> Hi Bruce,
> 
> On Wed, Apr 15, 2026 at 6:49 AM Bruce Momjian <bruce@momjian.us> wrote:
> 
>     I have completed the first draft of the PG 19 release notes:
> 
>             https://www.postgresql.org/docs/devel/release-19.html
> 
> 
> Thanks for working on this.
> 
> I noticed the notes don't mention the pg_rewind improvement committed in
> 5173bfd0 ("pg_rewind: Skip copy of WAL segments generated before point of
> divergence") [0].
> 
> [0] - https://www.postgresql.org/message-id/flat/
> 181b4c6fa9c.b8b725681941212.7547232617810891479%40viggy28.dev

True.  In reading the commit message, it seems like a minor improvement
that wasn't worth mentioning;   it says:

	This commit makes the way WAL segments are handled from the source
	to the target server slightly smarter:
	                     ----------------

and

	This change can make the rewind operation cheaper in some
	configurations, especially for setups where some WAL retention
	causes many segments to remain on the source server even after the
	promotion of a standby used as source to rewind a previous primary.

It seemed like a nice improvement, but not something that would be
useful for the average user to know.

-- 
  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.

Re: First draft of PG 19 release notes

Fujii Masao <masao.fujii@gmail.com> — 2026-06-18T01:29:47Z

On Wed, Apr 15, 2026 at 10:19 AM Bruce Momjian <bruce@momjian.us> wrote:
>
> I have completed the first draft of the PG 19 release notes:

Thanks for working on the release note!

    Reduce lock level of ALTER DOMAIN ... VALIDATE CONSTRAINT to match
ALTER TABLE ... VALIDATE CONSTRAINT (Jian He) §

I reverted this change at commit 64797ad97d6, so could you please
remove this item from the release notes?

Regards,

-- 
Fujii Masao

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-06-18T01:34:38Z

On Thu, Jun 18, 2026 at 10:29:47AM +0900, Fujii Masao wrote:
> On Wed, Apr 15, 2026 at 10:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > I have completed the first draft of the PG 19 release notes:
> 
> Thanks for working on the release note!
> 
>     Reduce lock level of ALTER DOMAIN ... VALIDATE CONSTRAINT to match
> ALTER TABLE ... VALIDATE CONSTRAINT (Jian He) §
> 
> I reverted this change at commit 64797ad97d6, so could you please
> remove this item from the release notes?

Oh, I missed that one, removed, 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.

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-06-18T01:45:48Z

On Wed, Jun 17, 2026 at 09:34:38PM -0400, Bruce Momjian wrote:
> On Thu, Jun 18, 2026 at 10:29:47AM +0900, Fujii Masao wrote:
> > On Wed, Apr 15, 2026 at 10:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> > >
> > > I have completed the first draft of the PG 19 release notes:
> > 
> > Thanks for working on the release note!
> > 
> >     Reduce lock level of ALTER DOMAIN ... VALIDATE CONSTRAINT to match
> > ALTER TABLE ... VALIDATE CONSTRAINT (Jian He) §
> > 
> > I reverted this change at commit 64797ad97d6, so could you please
> > remove this item from the release notes?
> 
> Oh, I missed that one, removed, thanks.

Ah, I missed it because it happened today and I was only current as of
yesterday.  I have now updated to be current as of today.

-- 
  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.

Re: First draft of PG 19 release notes

Chao Li <li.evan.chao@gmail.com> — 2026-06-25T02:57:47Z


> On Jun 18, 2026, at 09:45, Bruce Momjian <bruce@momjian.us> wrote:
> 
> On Wed, Jun 17, 2026 at 09:34:38PM -0400, Bruce Momjian wrote:
>> On Thu, Jun 18, 2026 at 10:29:47AM +0900, Fujii Masao wrote:
>>> On Wed, Apr 15, 2026 at 10:19 AM Bruce Momjian <bruce@momjian.us> wrote:
>>>> 
>>>> I have completed the first draft of the PG 19 release notes:
>>> 
>>> Thanks for working on the release note!
>>> 
>>>    Reduce lock level of ALTER DOMAIN ... VALIDATE CONSTRAINT to match
>>> ALTER TABLE ... VALIDATE CONSTRAINT (Jian He) §
>>> 
>>> I reverted this change at commit 64797ad97d6, so could you please
>>> remove this item from the release notes?
>> 
>> Oh, I missed that one, removed, thanks.
> 
> Ah, I missed it because it happened today and I was only current as of
> yesterday.  I have now updated to be current as of today.
> 
> -- 
>  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.

Hi, Bruce,

I noticed a typo in the item about “2026-03-27 [d7965d65f] Add rudimentary table prioritization to autovacuum”. The line is quite long, so I attached a diff file for your convenience.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us> — 2026-06-29T21:39:37Z

On Thu, Jun 25, 2026 at 10:57:47AM +0800, Chao Li wrote:
> 
> 
> > On Jun 18, 2026, at 09:45, Bruce Momjian <bruce@momjian.us> wrote:
> > 
> > On Wed, Jun 17, 2026 at 09:34:38PM -0400, Bruce Momjian wrote:
> >> On Thu, Jun 18, 2026 at 10:29:47AM +0900, Fujii Masao wrote:
> >>> On Wed, Apr 15, 2026 at 10:19 AM Bruce Momjian <bruce@momjian.us> wrote:
> >>>> 
> >>>> I have completed the first draft of the PG 19 release notes:
> >>> 
> >>> Thanks for working on the release note!
> >>> 
> >>>    Reduce lock level of ALTER DOMAIN ... VALIDATE CONSTRAINT to match
> >>> ALTER TABLE ... VALIDATE CONSTRAINT (Jian He) §
> >>> 
> >>> I reverted this change at commit 64797ad97d6, so could you please
> >>> remove this item from the release notes?
> >> 
> >> Oh, I missed that one, removed, thanks.
> > 
> > Ah, I missed it because it happened today and I was only current as of
> > yesterday.  I have now updated to be current as of today.

Ah, I missed adding the "autovacuum_" prefix, committed.

-- 
  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.

Re: First draft of PG 19 release notes

Andreas Karlsson <andreas@proxel.se> — 2026-07-02T22:12:37Z

Hi,

I noticed that some of the OAuth-realted items ended up under the wrong 
sections. See my suggestions below and the attached patch.

Jacob, do you have any opinion here?

= Add a new OAUTH flow hook PQAUTHDATA_OAUTH_BEARER_TOKEN_V2

Should go under "libpq"

= Allow custom OAUTH validators to register custom pg_hba.conf 
authentication options

Should go under "Server Configuration". It could arguably go under 
"Source Code" too but that seems less useful to the reader.

= Allow OAUTH validators to supply failure details

Should go under "Source Code" as this is not user facing.

--
Andreas Karlsson
Percona

Re: First draft of PG 19 release notes

Andreas Karlsson <andreas@proxel.se> — 2026-07-02T22:16:05Z

On 7/3/26 00:12, Andreas Karlsson wrote:
> I noticed that some of the OAuth-realted items ended up under the wrong 
> sections. See my suggestions below and the attached patch.
Ops, right patch attached now.

--
Andreas Karlsson
Percona

Re: First draft of PG 19 release notes

Jacob Champion <jacob.champion@enterprisedb.com> — 2026-07-02T22:35:59Z

On Thu, Jul 2, 2026 at 3:12 PM Andreas Karlsson <andreas@proxel.se> wrote:
> Jacob, do you have any opinion here?

I've got a TODO to edit the feature docs that I haven't been able to
check off yet. But no objections to your proposed moves at the moment
(they might need to move again when I really sit down and stare at
them).

Thanks!
--Jacob