From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Tomas Vondra <tomas(at)vondra(dot)me>, Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Greg Sabino Mullane <htamfids(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, Michael Banck <mbanck(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Enable data checksums by default |
Date: | 2025-05-23 08:10:47 |
Message-ID: | 0f191593-6901-490e-9830-aca099456e59@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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)
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2025-05-23 08:21:42 | Re: Retiring some encodings? |
Previous Message | Álvaro Herrera | 2025-05-23 07:54:54 | Re: PG 18 release notes draft committed |