On Fri, Apr 6, 2018 at 2:03 AM, Andrew Dunstan < andrew.duns...@2ndquadrant.com> wrote:
> On Fri, Apr 6, 2018 at 5:35 AM, Magnus Hagander <mag...@hagander.net> > wrote: > > Allow on-line enabling and disabling of data checksums > > > > This makes it possible to turn checksums on in a live cluster, without > > the previous need for dump/reload or logical replication (and to turn it > > off). > > > > Enabling checkusm starts a background process in the form of a > > launcher/worker combination that goes through the entire database and > > recalculates checksums on each and every page. Only when all pages have > > been checksummed are they fully enabled in the cluster. Any failure of > > the process will revert to checksums off and the process has to be > > started. > > > > This adds a new WAL record that indicates the state of checksums, so > > the process works across replicated clusters. > > > > > This has broken the buildfarm's cross-version upgrade testing (yes, we > do it for same-version upgrade as well as previous version upgrade). > > For now I have fixed crake by adding code to disable checksums in the > saved cluster. That at least will send crake green. Not sure if it's > the fix we want, though. Maybe we should test if checksums are enabled > on the upgraded cluster and if so enable them on the new cluster via > initdb. When we decide on the best fix I will put out a new release. > I'm unsure of why it actually leaves the cluster with checksums on. Which steps leaves it with checksums on? The last step of the checksum specific tests actually turns them *off* again. At which point in the series does it actually get the cluster to upgrade? -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
