Re: Offline enabling/disabling of data checksums - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Offline enabling/disabling of data checksums
Date
Msg-id alpine.DEB.2.21.1903131037240.4059@lancre
Whole thread Raw
In response to Re: Offline enabling/disabling of data checksums  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Offline enabling/disabling of data checksums
List 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.


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Offline enabling/disabling of data checksums
Next
From: Amit Langote
Date:
Subject: Re: Inadequate executor locking of indexes