> 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 page. -- David Christensen End Point Corporation da...@endpoint.com 785-727-1171 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
