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

From Daniel Gustafsson
Subject Re: Enable data checksums by default
Date
Msg-id pab_LcKKbQtxu9JUmu_Rwe2ugslnCPDqcJTpSvhVDY7S-FMOIvUHUsiXqfyq_bCvvgNXURDNRDEuCM3yTXFwMPG3DDp4QANe5NFcohFz7-k=@yesql.se
Whole thread Raw
In response to Re: Enable data checksums by default  (Andres Freund <andres@anarazel.de>)
Responses Re: Enable data checksums by default
List pgsql-hackers
On Thursday, April 11, 2019 6:58 PM, Andres Freund <andres@anarazel.de> wrote:

> On 2019-04-09 23:11:03 -0400, Bruce Momjian wrote:
>
> > Enabling checksums by default will require anyone using pg_upgrade to
> > run initdb to disable checksums before running pg_upgrade, for one
> > release. We could add checksums for non-link pg_upgrade runs, but we
> > don't have code to do that yet, and most people use link anyway.
>
> Hm. We could just have pg_ugprade run pg_checksums --enable/disable,
> based on the old cluster, and print a warning on mismatches. Not sure if
> that's worth it, but ...

That would be for link mode, for copy-mode you'd have to initdb with checksums
turned off and run pg_checksums on the new cluster, else the non-destructive
nature of copy mode would be lost.

Another option would be to teach pg_upgrade to checksum the cluster during the
upgrade on the fly.  That would however be a big conceptual change for
pg_upgrade as it's currently not modifying the cluster data.  In Greenplum we
have done this, but it was an easier choice there as we are rewriting all the
pages anyways.  It would also create yet another utility which can checksum an
offline cluster, but wanted to bring the idea to the table.

cheers ./daniel



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: setLastTid() and currtid()
Next
From: Peter Geoghegan
Date:
Subject: Re: Reducing the runtime of the core regression tests