Re: subscriptionCheck failures on nightjar - Mailing list pgsql-hackers

From Andres Freund
Subject Re: subscriptionCheck failures on nightjar
Date
Msg-id 20190213174151.mfylkessxmapt4io@alap3.anarazel.de
Whole thread Raw
In response to Re: subscriptionCheck failures on nightjar  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: subscriptionCheck failures on nightjar  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2019-02-13 12:37:35 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2019-02-13 11:57:32 -0500, Tom Lane wrote:
> >> I've managed to reproduce this locally, and obtained this PANIC:
> 
> > Cool. How exactly?
> 
> Andrew told me that nightjar is actually running in a qemu VM,
> so I set up freebsd 9.0 in a qemu VM, and boom.  It took a bit
> of fiddling with qemu parameters, but for such a timing-sensitive
> problem, that's not surprising.

Ah.


> >> I also wonder why bother with the directory sync just before the
> >> rename.
> 
> > Because on some FS/OS combinations the size of the renamed-into-place
> > file isn't guaranteed to be durable unless the directory was
> > fsynced.
> 
> Bleah.  But in any case, the rename should not create a situation
> in which we need to fsync the file data again.

Well, it's not super well defined which of either you need to make the
rename durable, and it appears to differ between OSs. Any argument
against fixing it up like I suggested, by using an fd from before the
rename?

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: reducing isolation tests runtime
Next
From: Andres Freund
Date:
Subject: Re: reducing isolation tests runtime