Re: PG 16 draft release notes ready
Bruce Momjian <bruce@momjian.us>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Revert MAINTAIN privilege and pg_maintain predefined role.
- 151c22deee66 17.0 cited
-
doc: PG 16 relnotes, remove "Have initdb use ICU by default"
- c729642bd760 16.0 cited
-
initdb: change default --locale-provider back to libc.
- 2535c74b1a61 16.0 cited
-
doc: PG 16 relnotes, add author
- b9e3f8005c99 16.0 landed
-
doc: PG 16 relnotes, move memory item and reword OUTER item
- e6a254c0d4af 16.0 landed
-
doc: PG 16 relnotes, add memory overhead reduction item
- 409d24485cbe 16.0 landed
-
doc: PG 16 relnotes, adjust subscription origin mention
- f7c16a120cfa 16.0 landed
-
doc: PG 16 relnotes, adjust auto_explain logging item
- 0bcb3ca3b95b 16.0 landed
-
doc: PG 16 relnotes: adjust outer/full hash join parallelization
- 5a6464096622 16.0 landed
-
doc: PG 16 relnotes, fix duplicate author and commit
- 9e28b83ae6fa 16.0 landed
-
doc: PG 16 relnotes, fix "locale" typo and windows locale text
- 503b0556d96f 16.0 landed
-
doc: PG 16 relnotes, add author from previous merge
- 46ba86cd32dc 16.0 landed
-
doc: PG 16 relnotes, wording adjustments
- 5c2c59ba0b5f 16.0 landed
-
doc: PG 16 relnotes, merge and move vector items
- ad5406246bff 16.0 landed
-
doc: PG 16 relnotes, update xid/subxid searches item
- a817edbf6f30 16.0 landed
-
doc: PG 16 relnotes, SIMD improvements
- 5cb54fc310fb 16.0 landed
-
doc: PG 16 relnotes, add major features list
- 60751aa50313 16.0 landed
-
doc: PG 16 relnotes, misc merged items and bootstrap detail
- de7c3fd34e0f 16.0 landed
-
doc: PG 16 relnotes, misc. updates
- c822358a256c 16.0 landed
-
doc: PG 16 relnotes, add commits
- 30579d23b226 16.0 landed
-
Allow logical decoding on standbys
- 0fdab27ad68a 16.0 cited
-
Fix ts_headline() edge cases for empty query and empty search text.
- 029dea882a7a 16.0 cited
-
Add a hook for modifying the ldapbind password
- 419a8dd8142a 16.0 cited
-
Rework design of functions in pg_walinspect
- 5c1b6628075a 16.0 cited
-
initdb: derive encoding from locale for ICU; similar to libc.
- c45dc7ffbba2 16.0 cited
-
Doc: add XML ID attributes to <sectN> and <varlistentry> tags.
- 78ee60ed84bb 16.0 cited
-
Simplify the implementations of the to_reg* functions.
- 3ea7329c9a79 16.0 cited
-
Rename pg_dissect_walfile_name() to pg_split_walfile_name()
- 13e0d7a60385 16.0 cited
-
Make materialized views participate in predicate locking
- 43351557d0d2 16.0 cited
-
Improve performance of and reduce overheads of memory management
- c6e0fe1f2a08 16.0 cited
-
Allow grant-level control of role inheritance behavior.
- e3ce2de09d81 16.0 cited
On Thu, May 18, 2023 at 02:53:25PM -0700, Peter Geoghegan wrote: > On Thu, May 18, 2023 at 1:49 PM Bruce Momjian <bruce@momjian.us> wrote: > > I will adjust it to the feedback I receive; that URL will quickly show > > all updates. > > > > I learned a few things creating it this time: > > > > * I can get confused over C function names and SQL function names in > > commit messages. > > The commit history covering pg_walinspect was complicated. Some of the > newly added stuff was revised multiple times, by multiple authors due > to changing ideas about the best UI. Here is some concrete feedback > about that: > > * Two functions that were in 15 that each end in *_till_end_of_wal() > were removed for 16, since the same functionality is now provided > through a more intuitive UI: we now tolerate invalid end_lsn values > "from the future", per a new "Tip" in the pg_walinspect documentation > for 16. > > In my opinion this should (at most) be covered as a compatibility > item. It's not really new functionality. So, I looked at this and the problem is that this is best as a single release note entry because we are removing and adding, and if I moved it to compatibility, I am concerned the new feature will be missed. Since WAL inspection is a utility operation, inn general, I think having it in the pg_walinspect section makes the most sense. > * There is one truly new pg_walinspect function added to 16: > pg_get_wal_block_info(). Its main purpose is to see how each > individual block changed -- it's far easier to track how blocks > changed over time using the new function. The original "record > orientated" functions made that very difficult (regex hacks were > required). > > pg_get_wal_block_info first appeared under another name, and had > somewhat narrower functionality to the final version, all of which > shouldn't matter to users -- since they never saw a stable release > with any of that. There is no point in telling users about the commits > that changed the name/functionality of pg_get_wal_block_info that came > only a couple of months after the earliest version was commited -- to > users, it is simply a new function with new functionality. Right. > I also suggest merging the pg_waldump items with the section you've > added covering pg_walinspect. A "pg_walinspect and pg_waldump" section > seems natural to me. Some of the enhancements in this area benefit > pg_walinspect and pg_waldump in exactly the same way, since > pg_walinspect is essentially a backend/SQL interface equivalent of > pg_waldump's frontend/CLI interface. Melanie's work on improving the > descriptions output for WAL records like Heap's PRUNE and VACUUM > records is a great example of this -- it does exactly the same thing > for pg_walinspect and pg_waldump, without directly targeting either > (it also affects the wal_debug developer option). Well, pg_waldump is an installed binary while pg_walinspect is an extension, so I am not sure where I would put a merged section. > It might also make sense to say that the enhanced WAL record > descriptions from Melanie generally apply to records used by VACUUM > only. Okay, I went with: Improve descriptions of pg_walinspect WAL record descriptions (Melanie Plageman, Peter Geoghegan) > Note also that the item "Add pg_waldump option --save-fullpage to dump > full page images (David Christensen)" is tangentially related to > pg_get_wal_block_info(), since you can also get FPIs using > pg_get_wal_block_info() (in fact, that was originally its main > purpose). I'm not saying that you necessarily need to connect them > together in any way, but you might consider it. Well, there is so much _new_ in that tool that listing everything new seems confusing. FYI, I have just added an item about more aggressing freezing: <!-- Author: Peter Geoghegan <pg@bowt.ie> 2022-09-08 [d977ffd92] Instrument freezing in autovacuum log reports. Author: Peter Geoghegan <pg@bowt.ie> 2022-11-15 [9e5405993] Deduplicate freeze plans in freeze WAL records. Author: Peter Geoghegan <pg@bowt.ie> 2022-12-28 [1de58df4f] Add page-level freezing to VACUUM. --> <listitem> <para> During non-freeze operations, perform page freezing where appropriate Peter Geoghegan) </para> <para> This makes full-table freeze vacuums less necessary. </para> </listitem> All changes committed. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.