Re: First draft of the PG 15 release notes

On Mon, Jul 18, 2022 at 08:23:23PM -0500, Justin Pryzby wrote:
> > Increase hash_mem_multiplier default to 2.0 (Peter Geoghegan)
> > This allows query hash operations to use double the amount of work_mem memory as other operations.
>
> I wonder if it's worth pointing out that a query may end up using not just 2x
> more memory (since work_mem*hash_mem_multiplier is per node), but 2**N more,
> for N nodes.

Uh, I said "per operation" so people might realize there can be multiple
work_mem memory operations per query. I don't think I can do more in
this text. I can't think of a way to improve it without making it more
confusing.

> > Remove pg_dump's --no-synchronized-snapshots option since all supported server versions support synchronized snapshots (Tom Lane)
>
> It'd be better to put that after the note about dropping support for upgrading
> clusters older than v9.2 in psql/pg_dump/pg_upgrade.

Well, I put the --no-synchronized-snapshots item in incompatibilities
since it is a user-visible change that might require script adjustments.
However, I put the limit of pg_dump to 9.2 and greater into the pg_dump
section. Are you suggesting I move the--no-synchronized-snapshots item
down there? That doesn't match with the way I have listed other
incompatibilities so I am resistant to do that.

> > Enable system and TOAST btree indexes to efficiently store duplicates (Peter Geoghegan)
>
> Say "btree indexes on system [and TOAST] tables"

Okay, updated to:

Allow btree indexes on system and TOAST tables to efficiently
store duplicates (Peter Geoghegan)

> > Prevent changes to columns only indexed by BRIN indexes from disabling HOT updates (Josef Simanek)
>
> This was reverted

Ah, yes, removed.

> > Generate periodic log message during slow server starts (Nitin Jadhav, Robert Haas)
> messages plural
>
> > Messages report the cause of the delay. The time interval for notification is controlled by the new server variable log_startup_progress_interval.
> *The messages

Ah, yes, fixed.

> > Add server variable shared_memory_size to report the size of allocated shared memory (Nathan Bossart)
> > Add server variable shared_memory_size_in_huge_pages to report the number of huge memory pages required (Nathan Bossart)
>
> Maybe these should say server *parameter* since they're not really "variable".

Uh, I think of parameters as something passed. We do call them server
variables, or read-only server variables. I can add "read-only" but it
seems odd.

> > 0. Add support for LZ4 and Zstandard compression of server-side base backups (Jeevan Ladhe, Robert Haas)
> > 1. Allow pg_basebackup to use LZ4 and Zstandard compression on server-side base backup files (Dipesh Pandit, Jeevan Ladhe)
> > 2. Allow pg_basebackup's --compress option to control the compression method and options (Michael Paquier, Robert Haas)
> > New options include server-gzip (gzip on the server), client-gzip (same as gzip).
> > 3. Allow pg_basebackup to compress on the server side and decompress on the client side before storage (Dipesh Pandit)
> > This is accomplished by specifying compression on the server side and plain output format.
>
> I still think these expose the incremental development rather than the
> user-facing change.

Well, they are in different parts of the system, though they are clearly
all related. I am afraid merging them would be even more confusing.

> 1. It seems wrong to say "server-side" since client-side compression with
> LZ4/zstd is also supported.

Agreed. I changed it to:

Allow pg_basebackup to do LZ4 and Zstandard server-side compression
on base backup files (Dipesh Pandit, Jeevan Ladhe)

> 2. It's confusing to say that the new options are server-gzip and client-gzip,
> since it just mentioned new algorithms;

I see your point since there will be new options for LZ4 and Zstandard
too, so I just removed that paragraph.

> 3. I'm not sure this needs to be mentioned at all; maybe it should be a
> "detail" following the item about server-side compression.

See my concerns above --- it seems too complex to merge into something
else. However, I am open to an entire rewrite of these items.

> > Tables added to the listed schemas in the future will also be replicated.
>
> "Tables later added" is clearer. Otherwise "in the future" sounds like maybe
> in v16 or v17 we'll start replicating those tables.

Agreed, new wording:

Tables added later to the listed schemas will also be replicated.

> > Allow subscribers to stop logical replication application on error (Osumi Takamichi, Mark Dilger)
> "application" sounds off.

Agreed. New text is:

Allow subscribers to stop the application of logical replication
changes on error

> > Add new default WAL-logged method for database creation (Dilip Kumar)
> "New default" sounds off. Say "Add new WAL-logged method for database creation, used by default".

Agreed, new text:

Add new <acronym>WAL</acronym>-logged method for <link
linkend="sql-createdatabase">database creation</link> (Dilip Kumar)

This is the new default for database creation and avoids the need
for checkpoints during database creation; the old method is still
available.

> > Have pg_upgrade preserve relfilenodes, tablespace, and database OIDs between old and new clusters (Shruthi KC, Antonin Houska)
>
> "tablespace OIDs" or "tablespace and database OIDs and relfilenodes"

Good point, I went with:

Have <application>pg_upgrade</application> preserve tablespace
and database OIDs, and relfilenodes between old and new clusters
(Shruthi KC, Antonin Houska)

> > Limit support of pg_upgrade to old servers running PostgreSQL 9.2 and later (Tom Lane)
>
> The word "old" doesn't appear in the 2 release notes items about pg_dump and
> psql, and "old" makes it sound sounds like "antique" rather than "source".

Uh, so pg_upgrade uses the terms "old" and "new" in its option names,
e.g., oldbindir, newbindir. I don't think "source" would be an
improvement here.

> > Some internal-use-only types have also been assigned this column.
> this *value

Good point, I went with:

Some other internal-use-only values have also been assigned to
this column.

> > Allow custom scan provders to indicate if they support projections (Sven Klemm)
> > The default is now that custom scan providers can't support projections, so they need to be updated for this release.
>
> Per the commit message, they don't "need" to be updated.
> I think this should say "The default now assumes that a custom scan provider
> does not support projections; to retain optimal performance, they should be
> updated to indicate whether that's supported.

Okay, I went with this text:

The default is now that custom scan providers are assumed to not
support projections; those that do need to be updated for this
release.

Cumulative applied patch attached.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Indecision is a decision. Inaction is an action. Mark Batterson