From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PG 16 draft release notes ready |
Date: | 2023-05-19 03:12:39 |
Message-ID: | ZGbpJyUMunJ+krkn@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)momjian(dot)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(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2023-05-19 03:15:09 | Re: PG 16 draft release notes ready |
Previous Message | Kyotaro Horiguchi | 2023-05-19 03:07:56 | Re: walsender performance regression due to logical decoding on standby changes |