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: