Re: Offline enabling/disabling of data checksums
От | Fabien COELHO |
---|---|
Тема | Re: Offline enabling/disabling of data checksums |
Дата | |
Msg-id | alpine.DEB.2.21.1903131037240.4059@lancre обсуждение исходный текст |
Ответ на | Re: Offline enabling/disabling of data checksums (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Offline enabling/disabling of data checksums
|
Список | 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 по дате отправления: