Re: Offline enabling/disabling of data checksums

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Michael Banck <michael(dot)banck(at)credativ(dot)de>, Sergei Kornilov <sk(at)zsrv(dot)org>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Offline enabling/disabling of data checksums
Date: 2019-03-13 10:41:24
Message-ID: alpine.DEB.2.21.1903131123360.4059@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


>> 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).


Attachment Content-Type Size
checksum-fsync-reorder.patch text/x-diff 2.1 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2019-03-13 10:47:23 Re: Offline enabling/disabling of data checksums
Previous Message Michael Banck 2019-03-13 10:41:15 Re: Offline enabling/disabling of data checksums