Horton

Re: Enable data checksums by default

Tomas Vondra <tomas@vondra.me>

View thread
From: Tomas Vondra <tomas@vondra.me>
To: Peter Eisentraut <peter@eisentraut.org>, Heikki Linnakangas <hlinnaka@iki.fi>, Nathan Bossart <nathandbossart@gmail.com>
Cc: Greg Sabino Mullane <htamfids@gmail.com>, Bruce Momjian <bruce@momjian.us>, Michael Paquier <michael@paquier.xyz>, Michael Banck <mbanck@gmx.net>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-05-23T09:43:57Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Avoid BufferGetLSNAtomic() calls during nbtree scans.

  2. doc PG 18 relnotes: Add incompatibility note about checksums now default

  3. Fix pg_upgrade's cross-version tests when old < 18

  4. initdb: Change default to using data checksums.

  5. Allow TAP tests to force checksums off when calling init()

  6. initdb: Add new option "--no-data-checksums"

  7. Tweak docs to reduce possible impact of data checksums


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