Horton

Re: Enable data checksums by default

Peter Eisentraut <peter@eisentraut.org>

View thread
From: Peter Eisentraut <peter@eisentraut.org>
To: Heikki Linnakangas <hlinnaka@iki.fi>, Tomas Vondra <tomas@vondra.me>, 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:22:29Z
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

Attachments

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.