Re: PG 16 draft release notes ready - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: PG 16 draft release notes ready
Date
Msg-id ZGbpJyUMunJ+krkn@momjian.us
Whole thread Raw
In response to Re: PG 16 draft release notes ready  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On Thu, May 18, 2023 at 07:15:26PM -0700, Peter Geoghegan wrote:
> On Thu, May 18, 2023 at 6:44 PM Bruce Momjian <bruce@momjian.us> wrote:
> > > I don't understand what you mean by that. The changes to
> > > *_till_end_of_wal() (the way that those duplicative functions were
> > > removed, and more permissive end_lsn behavior was added) is unrelated
> > > to all of the other changes. Plus it's just not very important.
> >
> > I see what you mean now.  I have moved the function removal to the
> > incompatibilities section and kept the existing entry but remove the
> > text about the removed functions.
> 
> Your patch now has two separate items for "[5c1b66280] Rework design
> of functions in pg_walinspect", but even one item is arguably one too
> many. The "ending LSN" item (the second item for this same commit)

I see your point.  pg_get_wal_block_info() doesn't exist in pre-PG 16,
so I have removed that text from the release note item, but kept the
other two functions.

> should probably be removed altogether. If you're going to keep the
> sentences that appear under that second item, then it should at least
> be consolidated with the first item, in order that commit 5c1b66280
> isn't listed twice.

We can list items twice if they have different focuses.

> Note also that the patch doesn't remove a remaining reference to an
> update in how pg_get_wal_block_info() works, which (as I've said) is a
> brand new function as far as users are concerned. Users don't need to
> hear that it has been updated, since these release notes will also be
> the first time they've been presented with any information about
> pg_get_wal_block_info(). (This isn't very important; again, I suggest
> that you avoid saying anything about any specific function, even if
> you feel strongly that the "ending LSN" issue must be spelled out like
> this.)

Agreed.

> > > There is pretty much one truly new piece of functionality added to
> > > pg_walinspect (the function called pg_get_wal_block_info was added) --
> > > since the enhancement to rmgr description output applies equally to
> > > pg_waldump, no matter where you place it in the release notes. So not
> > > sure what you mean.
> >
> > I see what you mean now.  I have removed the mention of
> > pg_get_wal_block_info() and moved the three items back into the
> > extension section since there are only three pg_walinspect items now.
> 
> The wording for this item as it appears in the patch is: "Improve
> descriptions of pg_walinspect WAL record descriptions". I suggest the
> following wording be used instead: "Provide more detailed descriptions
> of certain WAL records in the output of pg_walinspect and pg_waldump".

I went with, "Add detailed descriptions of WAL records in pg_walinspect
and pg_waldump (Melanie Plageman, Peter Geoghegan)".

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: walsender performance regression due to logical decoding on standby changes
Next
From: Bruce Momjian
Date:
Subject: Re: PG 16 draft release notes ready