Horton

Thread

Commits

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

  1. doc PG 19 relnotes: more fixes

  2. doc PG 19 relnotes: various corrections

  3. doc PG 19 relnotes: adjust item to mention pg_replication_slots

  4. doc PG 19 relnotes: remove "Add fake LSN support to hash index"

  5. doc PG 19 relnotes: add two optimizer hooks

  6. doc PG 19 relnotes: remove "Optionally" for CPU optimizations

  7. doc PG 19 relnotes: adjustments/removal of items

  8. Use fake LSNs to improve nbtree dropPin behavior.

  9. Clean up ICU includes.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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