Re: First draft of the PG 15 release notes - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: First draft of the PG 15 release notes
Date
Msg-id YnvVwv1SmGocrl+y@momjian.us
Whole thread Raw
In response to Re: First draft of the PG 15 release notes  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List 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@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Should use MERGE use BulkInsertState ?
Next
From: Nathan Bossart
Date:
Subject: Re: Estimating HugePages Requirements?