Re: Enable data checksums by default

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.