On 23.05.25 10:10, Heikki Linnakangas wrote:
The point of the open item was (a) to make sure this is adequately
documented, for instance in the release notes, (b) to think about
technological solutions to simplify this, such as [0], and (c) to just
check the general feedback.
Nothing from [0] ended up being committed, so that part of obsolete.
The action for beta1 is (a). And then for (c) perhaps monitor the
feedback between beta1 and beta2.
[0]: https://www.postgresql.org/message-id/flat/57957aca-3eae-4106-
afb2-3008122b9950%40eisentraut.org
Ping: It's time to do something about this open item. (Or decide to do
nothing I guess). We're already in beta, but at the same time, we're
still early in the beta and now is the last chance for code changes
before 18 is shipped.
Aside from just documenting it,
We don't currently have anything in the release notes that calls this
out as a potential upgrading issue, so I propose the attached patch.
I see two things we could do:
1. Have pg_upgrade run initdb for you. It's always felt silly that you
need to run initdb with the new version yourself, when there's really
only one correct way to do it. pg_upgrade has all the checks to verify
that you did it right, so why doesn't it just do it itself? I think
that'd be a good long-term solution. Might be too late for 18, but I'm
not sure. If someone wrote the patch we could evaluate it. To use that
mode, the scripts calling pg_upgrade would need to be changed, though,
so we'd perhaps want to do #2 or something else in addition to this.
2. If the new cluster has checksums enabled, but the old one has them
disabled, have pg_upgrade disable checksums in the new cluster.
These would alter the pg_upgrade workflow in significant ways, so I
don't think this would be appropriate to change now. So far I haven't
heard any feedback about this, so I'm content with a documentation change.
From e16a2db21688b14bfc9394a22d7bff2e2d445c5b Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <pe...@eisentraut.org>
Date: Fri, 23 May 2025 11:16:04 +0200
Subject: [PATCH] doc PG 18 relnotes: Add incompatibility note about checksums
now default
---
doc/src/sgml/release-18.sgml | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/doc/src/sgml/release-18.sgml b/doc/src/sgml/release-18.sgml
index 246e49ce740..d0867b981c0 100644
--- a/doc/src/sgml/release-18.sgml
+++ b/doc/src/sgml/release-18.sgml
@@ -191,6 +191,27 @@ <title>Migration to Version 18</title>
<para>
These were previously zero-based.
</para>
+</listitem>
+
+<!--
+Author: Peter Eisentraut <pe...@eisentraut.org>
+2024-10-16 [04bec894a04] initdb: Change default to using data checksums.
+-->
+
+<listitem>
+<para>
+initdb defaults to enabling data checksums
+<ulink url="&commit_baseurl;04bec894a04">§</ulink>
+</para>
+
+<para>
+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 was
+initialized without checksums (the previous default), then the new cluster
+will need to be initialized with --no-data-checksums in order to allow
+pg_upgrade to succeed.
+</para>
</listitem>
</itemizedlist>
--
2.49.0
