Re: Enable data checksums by default

On 5/23/25 11:22, Peter Eisentraut wrote:
> 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.
>

Seems reasonable, although maybe it should say

... so if the old cluster does not have checksums enabled ...

instead of

... so if the old cluster was initialized without checksums ...

I mean, what matters is the current state, not how it was initialized.

>> 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.

How would #2 change pg_upgrade workflow? Isn't the whole point of that
change to keep the current workflow working?

Also, I'm not sure if "no feedback about this" is reliable. I have no
clue if people did any significant testing. Maybe people did a lot of
testing and the current state is fine. But it's more likely there was
little testing, in which case "no feedback" says nothing.

FWIW I would be +0.5 to just let pg_upgrade disable checksums.

regards

--
Tomas Vondra