Horton

Re: Offline enabling/disabling of data checksums

Fabien COELHO <coelho@cri.ensmp.fr>

View thread View on postgr.es
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Magnus Hagander <magnus@hagander.net>
Cc: Michael Paquier <michael@paquier.xyz>, Michael Banck <michael.banck@credativ.de>, Postgres hackers <pgsql-hackers@postgresql.org>
Date: 2018-12-27T11:26:26Z
Lists: pgsql-hackers 
>> For enable/disable, while the command is running, it should mark the 
>> cluster as opened to prevent an unwanted database start. I do not see 
>> where this is done.
>>
>> You have pretty much the same class of problems if you attempt to
>> start a cluster on which pg_rewind or the existing pg_verify_checksums
>> is run after these have scanned the control file to make sure that
>> they work on a cleanly-stopped instance. [...]
>
> I think it comes down to what the outcome is. If we're going to end up with
> a corrupt database (e.g. one where checksums aren't set everywhere but they
> are marked as such in pg_control) then it's not acceptable. If the only
> outcome is the tool gives an error that's not an error and if re-run it's
> fine, then it's a different story.

ISTM that such an outcome is indeed a risk, as a starting postgres could 
update already checksummed pages without putting a checksum. It could be 
even worse, although with a (very) low probability, with updates 
overwritten on a race condition between the processes. In any case, no 
error would be reported before much later, with invalid checksums or 
inconsistent data, or undetected forgotten committed data.

-- 
Fabien.

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/