From 37e5f0b61fa8aad82a0b06438ed95c282ace994a Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Sat, 7 Jun 2025 11:06:25 -0400 Subject: [PATCH 1/2] doc PG 18 relnotes: adjust wording of initdb item 48814415d5a And move to the top of the incompatibility list. This will impact users more than any other incompatibility item because of pg_upgrade. --- doc/src/sgml/release-18.sgml | 39 +++++++++++++++++------------------- 1 file changed, 18 insertions(+), 21 deletions(-) diff --git a/doc/src/sgml/release-18.sgml b/doc/src/sgml/release-18.sgml index 19e770c65b5dc..268fa88cbe0e7 100644 --- a/doc/src/sgml/release-18.sgml +++ b/doc/src/sgml/release-18.sgml @@ -53,6 +53,24 @@ + + + + +Change initdb default to enable data checksums +§ + + + +Checksums can be disabled with the new initdb option --no-data-checksums. +pg_upgrade requires matching cluster checksum settings, so this new +option can be useful to upgrade non-checksum old clusters. + + + - - - -initdb defaults to enabling data checksums -§ - - - -The previous default behavior (checksums disabled) can be obtained using the -new option --no-data-checksums. Note that pg_upgrade will reject upgrading -between clusters with different checksum settings, so if the old cluster does -not have checksums enabled (the previous default), then the new cluster will -need to be initialized with --no-data-checksums in order to allow pg_upgrade -to succeed. - From 73e26cbeb5927053eea4e209e5eda34a30c353f1 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Sat, 7 Jun 2025 11:25:17 -0400 Subject: [PATCH 2/2] doc PG 18 relnotes: add AFTER trigger user change item Reported-by: Noah Misch Discussion: https://postgr.es/m/20250603172123.5f.nmisch@google.com --- doc/src/sgml/release-18.sgml | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/doc/src/sgml/release-18.sgml b/doc/src/sgml/release-18.sgml index 268fa88cbe0e7..c5e60f88fdf15 100644 --- a/doc/src/sgml/release-18.sgml +++ b/doc/src/sgml/release-18.sgml @@ -157,6 +157,22 @@ Previously ALTER TABLE SET [UN]LOGGED did nothing, and the creation of an unlogg + + + + +Execute AFTER triggers as the role that was active when trigger events were queued (Laurenz Albe) + + + +Previously such triggers were run as the role that was active at trigger execution time (e.g., at COMMIT). This is significant for cases where the role is changed between queue time and +transaction commit. + + +