> On Jan 23, 2017, at 10:59 AM, David Christensen <da...@endpoint.com> wrote: > >> >> 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.
Another issue with this (that I think would still exist with the bgworker approach) is how to handle databases with datallowconn = 0. `vacuumdb`, at least, explicitly filters out these rows when iterating over databases to connect to, so while we could enable them for all databases, we can’t enable for the cluster without verifying that these disallowed dbs are already checksummed. -- 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
