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: