> On 25 Nov 2020, at 14:33, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> The lwlocking doesn't look right here. If ControlFile->data_checksum_version != PG_DATA_CHECKSUM_VERSION,
LWLockAcquireis called twice without a LWLockRelease in between.
Right, fixed.
> What if a checkpoint, and a crash, happens just after the WAL record has been written, but before the control file is
updated?That's a ridiculously tight window for a whole checkpoint cycle to happen, but in principle I think that would
spelltrouble. I think you could set delayChkpt to prevent the checkpoint from happening in that window, similar to how
weavoid this problem with the clog updates at commit. Also, I think this should be in a critical section; we don't want
theprocess to error out in between for any reason, and if it does happen, it's panic time.
Good points. The attached patch performs the state changes inside a critical
section with checkpoints delayed, as well as emit the barrier inside the
critical section while awaiting the barrier outside to keep it open as short as
possible.
I've also done some tweaks to the tests to make them more robust as well as
comment updates and general tidying up here and there.
cheers ./daniel