|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
>> 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
> 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).
|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|