Re: [DESIGN] Incremental checksums - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [DESIGN] Incremental checksums
Date
Msg-id CAA4eK1Kwp4yHxekpO86rkyJySGJL1zz0he9rsMnC0e1FceEpRg@mail.gmail.com
Whole thread Raw
In response to Re: [DESIGN] Incremental checksums  (David Christensen <david@endpoint.com>)
Responses Re: [DESIGN] Incremental checksums  (David Christensen <david@endpoint.com>)
List pgsql-hackers
On Wed, Jul 15, 2015 at 9:13 PM, David Christensen <david@endpoint.com> wrote:
>
>
> > On Jul 15, 2015, at 3:18 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > >   - pg_disable_checksums(void) => turn checksums off for a cluster.  Sets the state to "disabled", which means bg_worker will not do anything.
> > >
> > >   - pg_request_checksum_cycle(void) => if checksums are "enabled", increment the data_checksum_cycle counter and set the state to "enabling".
> > >
> >
> > If the cluster is already enabled for checksums, then what is
> > the need for any other action?
>
> You are assuming this is a one-way action.  
>

No, I was confused by the state (enabling) this function will set.

> Requesting an explicit checksum cycle would be desirable in the case where you want to proactively verify there is no cluster corruption to be found.
>

Sure, but I think that is different from setting the state to enabling.
In your proposal above, in enabling state cluster needs to write
checksums, where for such a feature you only need read validation.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [PATCH] postgres_fdw extension support
Next
From: Pavel Stehule
Date:
Subject: option for psql - short list non template database