Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us>

From: Bruce Momjian <bruce@momjian.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, David Geier <geidav.pg@gmail.com>, PostgreSQL-development <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-21T20:18:40Z
Lists: pgsql-hackers
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.



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: remove VALIDATE CONSTRAINT lock item

  2. Fix ALTER DOMAIN VALIDATE CONSTRAINT locking

  3. Revert "Enable fast default for domains with non-volatile constraints"

  4. doc PG 19 relnotes: improve awkward or confusing wording

  5. doc PG 19 relnotes: more fixes

  6. doc PG 19 relnotes: various corrections

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

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

  9. doc PG 19 relnotes: add two optimizer hooks

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

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

  12. doc PG 19 relnotes: add UTF-8 case folding performance item

  13. doc PG 19 relnotes: correct two items

  14. doc PG 19 relnotes: add missing commits and details

  15. doc PG 19 relnotes: fix typo, "date" -> "data"

  16. doc PG 19 relnotes: add author and move items

  17. doc PG 19 relnotes: update author

  18. doc PG 19 relnotes: add free space map all-visible item

  19. doc PG 19 relnotes: remove "Lakshmi N" as author of checksums

  20. doc PG 19 relnotes: fix "now targets"

  21. doc PG 19 relnotes: adjust ShmemRequestStruct item

  22. Improve various new-to-v19 appendStringInfo calls

  23. doc: Fix data_checksums data type

  24. Fix WITHOUT OVERLAPS' interaction with domains.

  25. Online enabling and disabling of data checksums

  26. Doc: split functions-posix-regexp section into multiple subsections.

  27. make immutability tests in to_json and to_jsonb complete

  28. Optimize tuple deformation

  29. pgstattuple: Optimize pgstattuple_approx() with streaming read

  30. Use fake LSNs to improve nbtree dropPin behavior.

  31. Use streaming read for VACUUM cleanup of GIN

  32. Clean up ICU includes.

  33. ICU: use UTF8-optimized case conversion API

  34. Add the MODE option to the WAIT FOR LSN command

  35. Speedup tuple deformation with additional function inlining