From: | "Brad Nicholson" <bradn(at)ca(dot)ibm(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Enabling checksums on a streaming replica |
Date: | 2019-06-26 15:32:11 |
Message-ID: | OF197FCF62.18B58E9B-ON85258425.00531EC6-85258425.0055585E@notes.na.collabserv.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I'm wondering about the validity of using the pg_checksums utility to
enable checksum's on a streaming replication standby, and then promoting
that standby as a way to enable checksums on existing clusters.
I've tested the process out, and it "works" (by works I mean doesn't blow
up or log any errors). But this seems far enough outside of supported
territory that I'm curious what others think.
The process is:
- Primary with checksums off
- create a streaming replica off that primary
- stop the secondary
- enable checksums on the secondary with the pg_checksums utility
- start the replica
- promote the replica
I've thrown load at it while the it was replicating from checksums off ->
checksums on, promoted it, and verified the checksums after with
pg_checksums.
Any thoughts on this approach?
Thanks,
Brad
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2019-06-26 16:09:08 | Re: REINDEX : new parameter to preserve current average leaf density as new implicit FILLFACTOR |
Previous Message | Jesper Pedersen | 2019-06-26 15:05:54 | pg_receivelwal vs synchronous |