Feedback-ID: ie3de48e3:Fastmail
Date: Sat, 6 Jun 2026 15:08:05 +0200
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de>
To: Bruce Momjian <bruce@momjian.us>
Cc: Yugo Nagata <nagata@sraoss.co.jp>,
	PostgreSQL-development <pgsql-hackers@lists.postgresql.org>
Subject: Re: First draft of PG 19 release notes
Message-ID: <aiQPgZtALNqj4npv@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <aiMcYbhya9eqF4Zr@momjian.us>
Archived-At: 
 <https://www.postgresql.org/message-id/aiQPgZtALNqj4npv%40alvherre.pgsql>
Precedence: bulk

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"