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 |
Thread: | |
Lists: | pgsql-hackers |
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.
Attachment | Content-Type | Size |
---|---|---|
checksum-fsync-reorder.patch | text/x-diff | 2.1 KB |
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 |