Re: Enable data checksums by default - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Enable data checksums by default
Date
Msg-id 0f191593-6901-490e-9830-aca099456e59@iki.fi
Whole thread Raw
In response to Re: Enable data checksums by default  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: Enable data checksums by default
Re: Enable data checksums by default
List pgsql-hackers
On 24/04/2025 14:26, Peter Eisentraut wrote:
> On 23.04.25 00:24, Tomas Vondra wrote:
>>> The patch that flips the default has been committed.
>>>
>>> I also started a PG18 open items page and made a note that we follow up
>>> on the upgrade experience, as was discussed in this thread.
>>>
>>> https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items
>>>
>> Regarding the open item, can someone explain what exactly are we
>> planning to evaluate mid-beta?
> 
> If you have a PG <=17 installation without checksums (the default), and 
> you do the usual upgrade procedure to PG 18 involving initdb + 
> pg_upgrade, then pg_upgrade will reject the upgrade, because the 
> checksum settings don't match.  The workaround is to run initdb with -- 
> no-data-checksums and try again.
> 
> That's probably not all that bad, but if this is all below a bunch of 
> layers of scripts, users will have to do some work on their end to get 
> this working smoothly.
> 
> 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, 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.

-- 
Heikki Linnakangas
Neon (https://neon.tech)




pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: PG 18 release notes draft committed
Next
From: Daniel Gustafsson
Date:
Subject: Re: Retiring some encodings?