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/>

Reply via email to