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

From Andres Freund
Subject Re: Enable data checksums by default
Date
Msg-id 20190411185641.czkxd36iiouib5dd@alap3.anarazel.de
Whole thread Raw
In response to Re: Enable data checksums by default  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Enable data checksums by default
List pgsql-hackers
Hi,

On 2019-04-11 18:15:41 +0000, Daniel Gustafsson wrote:
> 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.

I don't think so? But I think we might just have misunderstood each
other. What I was suggesting is that we could take the burden of having
to match the old cluster's checksum enabled/disabled setting when
initdb'ing the new cluster, by changing the new cluster instead of
erroring out with:
    if (oldctrl->data_checksum_version == 0 &&
        newctrl->data_checksum_version != 0)
        pg_fatal("old cluster does not use data checksums but the new one does\n");
    else if (oldctrl->data_checksum_version != 0 &&
             newctrl->data_checksum_version == 0)
        pg_fatal("old cluster uses data checksums but the new one does not\n");
    else if (oldctrl->data_checksum_version != newctrl->data_checksum_version)
        pg_fatal("old and new cluster pg_controldata checksum versions do not match\n");


As the new cluster at that time isn't yet related to the old cluster, I
don't see why that'd influence the non-destructive nature?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Reducing the runtime of the core regression tests
Next
From: Michael Meskes
Date:
Subject: Re: fix memory overflow in ecpg preproc module