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-13T10:41:24Z
Lists: pgsql-hackers

Attachments

Hello,

>> 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.
>
> Well, pg_rewind works similarly: control file gets updated and then
> the whole data directory gets flushed.

So it is basically prone to the same potential issue?

> In my opinion, the take here is that we log something after the sync of 
> the whole data folder is done, so as in the event of a crash an operator 
> can make sure that everything has happened.

I do not understand. I'm basically only suggesting to reorder 3 lines and 
add an fsync so that this potential problem goes away, see attached poc 
(which does not compile because pg_fsync is in the backend only, however 
it works with fsync but on linux, I'm unsure of the portability, 
probably pg_fsync should be moved to port or something).

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