Re: First draft of the PG 15 release notes

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: First draft of the PG 15 release notes
Date: 2022-05-11 15:26:58
Message-ID: YnvVwv1SmGocrl+y@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 11, 2022 at 04:12:23PM +0200, Álvaro Herrera wrote:
> I think this item is pointless:
>
> Remove unused function parameter in get_qual_from_partbound() (Hou Zhijie)
>
> it's just a C-level code, and we don't document such API changes. If we
> were to document them all, it'd be a very very long document.

Okay, removed. I had added it because of this commit text:

This is an external function that extensions could use, so this is
potentially a breaking change. No external callers are known, however,
and this will make it simpler to write such callers in the future.

> Here:
> Improve the algorithm used to compute random() (Fabien Coelho)
>
> This will cause setseed() followed by random() to return a different
> value than on older servers.
> Maybe it's clearer as "This will cause random() sequences to differ from
> what was emitted by prior versions for the same seed values." If I
> don't know anything about the random() API, I understand this as saying
> that setseed() returns a value, and we only changed that value when
> random() is called afterwards.

Yes, better, thanks.

> Here:
> Fix ALTER TRIGGER RENAME on partitioned tables to rename partitions
> (Arne Roland, Álvaro Herrera)
>
> Also prohibit cloned triggers from being renamed.
>
> "... to rename the corresponding triggers on partitions.
>
> Also prohibit such triggers on partitions from being renamed."
> (It's not the *partitions* that are renamed but the triggers,
> obviously.)

Okay, new text:

Fix ALTER TRIGGER RENAME on partitioned tables to properly rename
triggers an all partitions (Arne Roland, Álvaro Herrera)

> Here:
> Add server variable recursive_worktable_factor to allow the user to
> specify the expected recursive query worktable size (Simon Riggs)
>
> WHAT IS A WORKTABLE? NOT DEFINED.
> Do we need to explain in the relnotes that this is relevant to planning
> of WITH RECURSIVE queries?

You mean the syntax? I figured "recursive query" was enough, but the
item clearly needs help.

> Generate periodic log message during slow server starts (Nitin Jadhav,
> Robert Haas, Álvaro Herrera)
> Please credit only Nitin and Robert, not me. I only edited the docs.

Okay, done.

> Allow members of the pg_checkpointer predefined role to run the
> CHECKPOINT command (Jeff Davis)
>
> The 11-era entry said that we *added* new roles for the tasks, and I
> think we should do likewise here:
> Add predefined role pg_checkpointer that enables to run CHECKPOINT
> Otherwise it sounds like pg_checkpointer already existed and we gave it
> this new responsibility.

Agreed, much better. New text:

Add predefined role pg_checkpointer that allows members to run
CHECKPOINT (Jeff Davis)

> Here:
> Create unlogged sequences and allow them to be skipped in logical
> replication (Peter Eisentraut)
> This is not specific to logical replication, actually; it's a generic
> new feature of sequences. So I don't think it belongs in the logical
> replication section. But it's not clear to me where to put it.

Oh, yeah, I had it there because that was its value, but now that we
don't replication sequences, it needs to moved. I put it in the "Data
Types" section.

> Here:
> Add SQL MERGE command to adjust one table to match another (Pavan
> Deolasee, Álvaro Herrera, Amit Langote, Simon Riggs)
> I'm not sure this accurately describes the purpose of the command.
> Maybe "Add SQL MERGE command that allows to run INSERT, UPDATE, DELETE
> subcommands based on another table or the output of a query."

Uh, that sounds odd to me, though I realize it is accurate.

> Also, it doesn't belong in the Utilities section. Maybe it should be in
> the SELECT,INSERT section, and rename the section to something like
> "SQL Queries", and put the whole JSON subsection inside that section

Uh, SQL queries seems very vague --- isn't SELECT the only actual query,
and if not, aren't all commands queries.

> (rather than inside the Functions section).
> I think Simon should appear as first author here.

Done.

> Add new protocol message TARGET to specify a new COPY method to be for
> base backups (Robert Haas)
> I think this one should be in some other section, maybe "Streaming
> Replication and Recovery".

I didn't think anyone cared about the protocol so I put it in Source
Code.
>
> Add server variable archive_library to specify the library to be called
> for archiving (Nathan Bossart)
> Maybe "Allow site-specific WAL archiving, which may no longer use shell
> commands." or something to that effect? The reference to a library is
> a bit obscure.

I added this sentence below it:

Previously only shell commands could be called to perform archiving.

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

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2022-05-11 15:57:19 Re: Estimating HugePages Requirements?
Previous Message Alvaro Herrera 2022-05-11 15:23:27 Re: Should use MERGE use BulkInsertState ?