> On 23 May 2025, at 10:10, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> Aside from just documenting it, 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'mnot sure. If someone wrote the patch we could evaluate it. To use that mode, the scripts calling pg_upgrade would
needto be changed, though, so we'd perhaps want to do #2 or something else in addition to this.
I can see this being desired longer term, but as you mention there is likely to
be many moving parts outside of our immediate control making it much harder
than just adding the call to initdb. It doesn't seem like a post-beta patch to
me given the implications for packagers and others in the ecosystem.
> 2. If the new cluster has checksums enabled, but the old one has them disabled, have pg_upgrade disable checksums in
thenew cluster.
IF we do this it should be Very visible, since a user otherwise might think
that their upgraded cluster will have checksums since they added them in
initdb.
I think we should document how to deal with checksums in upgrades, and perhaps
even tweak the errormessage in the pg_upgrade check with explanatory comments
if needed, and leave the functionality as is today.
--
Daniel Gustafsson
