> On Jan 23, 2017, at 10:53 AM, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 23 January 2017 at 16:32, David Christensen <da...@endpoint.com> wrote:
>> ** Handling checksums on a standby:
>> How to handle checksums on a standby is a bit trickier since checksums are 
>> inherently a local cluster state and not WAL logged but we are storing state 
>> in the system tables for each database we need to make sure that the 
>> replicas reflect truthful state for the checksums for the cluster.
> Not WAL logged? If the objective of this feature is robustness, it
> will need to be WAL logged.
> Relation options aren't accessed by the startup process during
> recovery, so that part won't work in recovery. Perhaps disable
> checksumming until the everything is enabled rather than relation by
> relation.
> If y'all serious about this then you're pretty late in the cycle for
> such a huge/critical patch. So lets think of ways of reducing the
> complexity...
> Seems most sensible to add the "enable checksums for table" function
> into VACUUM because then it will happen automatically via autovacuum,
> or you could force the issue using something like
> vacuumdb --jobs 4 --enable-checksums
> That gives you vacuum_delay and a background worker for no effort

I’m not sure that this will work as-is, unless we’re forcing VACUUM to ignore 
the visibility map.  I had originally considered having this sit on top of 
VACUUm though, we just need a way to iterate over all relations and read every 

David Christensen
End Point Corporation

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to