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: Michael Paquier <michael@paquier.xyz>
Cc: Michael Banck <michael.banck@credativ.de>, Sergei Kornilov <sk@zsrv.org>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2019-03-13T09:44:03Z
Lists: pgsql-hackers 
>> I do not think it is a good thing that two commands can write to the data
>> directory at the same time, really.
>
> We don't prevent either a pg_resetwal and a pg_basebackup to run in
> parallel.  That would be...  Interesting.

Yep, I'm trying again to suggest that this kind of thing should be 
prevented. It seems that I'm pretty unconvincing.

>> About fsync-ing: ISTM that it is possible that the control file is written
>> to disk while data are still not written, so a failure in between would
>> leave the cluster with an inconsistent state. I think that it should fsync
>> the data *then* update the control file and fsync again on that one.
>
> if --enable is used, we fsync the whole data directory after writing
> all the blocks and updating the control file at the end. [...]
> It could be possible to reach a state where the control file has 
> checksums enabled and some blocks are not correctly synced, still you 
> would notice rather quickly if the server is in an incorrect state at 
> the follow-up startup.

Yep. That is the issue I think is preventable by fsyncing updated data 
*then* writing & syncing the control file, and that should be done by
pg_checksums.

-- 
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/