Re: subscriptionCheck failures on nightjar

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: subscriptionCheck failures on nightjar
Дата
Msg-id 31663.1550082243@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: subscriptionCheck failures on nightjar  (Andres Freund <andres@anarazel.de>)
Ответы Re: subscriptionCheck failures on nightjar  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: subscriptionCheck failures on nightjar
Следующее
От: Andres Freund
Дата:
Сообщение: Ought to use heap_multi_insert() for pg_attribute/depend insertions?