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

From Tom Lane
Subject Re: subscriptionCheck failures on nightjar
Date
Msg-id 31663.1550082243@sss.pgh.pa.us
Whole thread Raw
In response to Re: subscriptionCheck failures on nightjar  (Andres Freund <andres@anarazel.de>)
Responses Re: subscriptionCheck failures on nightjar  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2019-02-13 12:59:19 -0500, Tom Lane wrote:
>> Perhaps more to the point, the way this was coded, the PANIC applies
>> to open() failures in fsync_fname_ext() not just fsync() failures;
>> that's painting with too broad a brush isn't it?

> That indeed seems wrong. Thomas?  I'm not quite sure how to best fix
> this though - I guess we could rename fsync_fname_ext's eleval parameter
> to fsync_failure_elevel? It's not visible outside fd.c, so that'd not be
> to bad?

Perhaps fsync_fname() should pass the elevel through as-is, and
then fsync_fname_ext() apply the data_sync_elevel() promotion only
to the fsync() call not the open()?  I'm not sure.

The bigger picture here is that there are probably some call sites where
PANIC on open() failure is appropriate too.  So having fsync_fname[_ext]
deciding what to do on its own is likely to be inadequate.

If we fix this by allowing ENOENT to not be an error in this particular
call case, that's going to involve an fsync_fname_ext API change anyway...

            regards, tom lane


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: subscriptionCheck failures on nightjar
Next
From: Andres Freund
Date:
Subject: Ought to use heap_multi_insert() for pg_attribute/depend insertions?