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

From David Christensen
Subject Re: [DESIGN] Incremental checksums
Date
Msg-id 6AAE6E64-F17B-4577-A5BB-5DC6411C801D@endpoint.com
Whole thread Raw
In response to Re: [DESIGN] Incremental checksums  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
> > > >   - pg_disable_checksums(void) => turn checksums off for a cluster.  Sets the state to "disabled", which means
bg_workerwill not do anything. 
> > > >
> > > >   - pg_request_checksum_cycle(void) => if checksums are "enabled", increment the data_checksum_cycle counter
andset 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.

Okay.

> > Requesting an explicit checksum cycle would be desirable in the case where you want to proactively verify there is
nocluster 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 “revalidating” since your database is still actively making changes, you need to validate writes too (think new
tables,etc).  “Enabling” needs reads unvalidated because you’re starting from an unknown state (i.e., not checksummed
already).

Thanks,

David
--
David Christensen
PostgreSQL Team Manager
End Point Corporation
david@endpoint.com
785-727-1171








pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: optimizing vacuum truncation scans
Next
From: Petr Jelinek
Date:
Subject: Re: TABLESAMPLE patch is really in pretty sad shape