From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | David Christensen <david(at)endpoint(dot)com> |
Cc: | PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net> |
Subject: | Re: Online enabling of page level checksums |
Date: | 2017-01-23 16:53:27 |
Message-ID: | CANP8+jLQn4w48K+c2dLYMkiRNzzrZ6fN9Q3BxsbikrB4KRXsOQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 23 January 2017 at 16:32, David Christensen <david(at)endpoint(dot)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
Hope that helps
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2017-01-23 16:56:03 | Re: Logical Replication WIP |
Previous Message | Claudio Freire | 2017-01-23 16:49:03 | Re: Vacuum: allow usage of more than 1GB of work mem |