On Thursday, April 11, 2019 8:56 PM, Andres Freund <and...@anarazel.de> wrote:
> On 2019-04-11 18:15:41 +0000, Daniel Gustafsson wrote: > > > On Thursday, April 11, 2019 6:58 PM, Andres Freund and...@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? Right, now I see what you mean, and I indeed misunderstood you. Thanks for clarifying. cheers ./daniel