Horton

Re: Offline enabling/disabling of data checksums

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Magnus Hagander <magnus@hagander.net>
Cc: Sergei Kornilov <sk@zsrv.org>, Fabien COELHO <coelho@cri.ensmp.fr>, Michael Banck <michael.banck@credativ.de>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2019-03-15T09:58:56Z
Lists: pgsql-hackers 
On Fri, Mar 15, 2019 at 09:52:11AM +0100, Magnus Hagander wrote:
> As I said, that's a big hammer. I'm all for having a better solution. But I
> don't think it's acceptable not to have *any* defense against it, given how
> bad corruption it can lead to.

Hm...  It looks that my arguments are not convincing enough.  I am not
really convinced that there is any need to make that the default, nor
does it make much sense to embed that stuff directly into pg_checksums
because that's actually just doing an extra step which is equivalent
to calling pg_resetwal, and we know that this tool has the awesome
reputation to cause more harm than anything else.  At least I would
like to have an option which allows to support the behavior to *not*
update the system identifier so as the cases I mentioned would be
supported, because then it becomes possible to enable checksums on a
primary with only a failover as long as page copies are not directly
involved and that all operations go through WAL.  And that would be
quite nice.
--
Michael

Commits

  1. Reorganize Notes section in documentation of pg_checksums

  2. Add option -N/--no-sync to pg_checksums

  3. Add options to enable and disable checksums in pg_checksums

  4. Refactor more code logic to update the control file

  5. Rename pg_verify_checksums to pg_checksums

  6. Fix cross-version compatibility checks of pg_verify_checksums

  7. Add routine able to update the control file to src/common/