From: | Tomas Vondra <tomas(at)vondra(dot)me> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org> |
Cc: | Greg Sabino Mullane <htamfids(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Enable data checksums by default |
Date: | 2024-08-08 18:49:36 |
Message-ID: | 6f117033-b2e5-45b5-8192-f1ebbc4312bf@vondra.me |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 8/8/24 19:42, Robert Haas wrote:
> On Thu, Aug 8, 2024 at 6:11 AM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>> About the claim that it's already the de-facto standard. Maybe that is
>> approximately true for "serious" installations. But AFAICT, the popular
>> packagings don't enable checksums by default, so there is likely a
>> significant middle tier between "just trying it out" and serious
>> production use that don't have it turned on.
>
> +1.
>
>> I'm thinking pg_upgrade could have a mode where it adds the
>> checksum during the upgrade as it copies the files (essentially a subset
>> of pg_checksums). I think that would be useful for that middle tier of
>> users who just want a good default experience.
>
> That would be very nice.
>
Yeah, but it might also disable checksums on the new cluster, which
would work for link mode too. So we'd probably want multiple modes, one
to enable checksums during file copy, one to disable checksums, and one
to just fail for incompatible clusters.
--
Tomas Vondra
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Jungwirth | 2024-08-08 18:50:57 | Re: Which parts of src/backend/nodes/print.c are used? |
Previous Message | Tomas Vondra | 2024-08-08 18:34:40 | Re: Add LSN <-> time conversion functionality |