Re: could not stat promote trigger file leads to shutdown

Поиск
Список
Период
Сортировка
Искать
От
Peter Eisentraut
Тема
Re: could not stat promote trigger file leads to shutdown
Дата
Msg-id
fa103866-894e-a2bc-067d-0d590d6fb7a0@2ndquadrant.com
Ответ на
Список
Дерево обсуждения
could not stat promote trigger file leads to shutdown Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Re: could not stat promote trigger file leads to shutdown Tom Lane <tgl@sss.pgh.pa.us>
Re: could not stat promote trigger file leads to shutdown Michael Paquier <michael@paquier.xyz>
Re: could not stat promote trigger file leads to shutdown Fujii Masao <masao.fujii@gmail.com>
Re: could not stat promote trigger file leads to shutdown Tom Lane <tgl@sss.pgh.pa.us>
Re: could not stat promote trigger file leads to shutdown Sergei Kornilov <sk@zsrv.org>
Re: could not stat promote trigger file leads to shutdown Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Re: could not stat promote trigger file leads to shutdown Tom Lane <tgl@sss.pgh.pa.us>
Re: could not stat promote trigger file leads to shutdown Alvaro Herrera <alvherre@2ndquadrant.com>
Re: could not stat promote trigger file leads to shutdown Tom Lane <tgl@sss.pgh.pa.us>
Re: could not stat promote trigger file leads to shutdown Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Re: could not stat promote trigger file leads to shutdown Tom Lane <tgl@sss.pgh.pa.us>
Re: could not stat promote trigger file leads to shutdown Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Re: could not stat promote trigger file leads to shutdown Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Re: could not stat promote trigger file leads to shutdown Michael Paquier <michael@paquier.xyz>
Re: could not stat promote trigger file leads to shutdown Fujii Masao <masao.fujii@gmail.com>
On 2019-11-20 16:21, Tom Lane wrote:
>> AFAICT, a GUC check hook wouldn't actually be able to address the
>> specific scenario I described.  At the time the GUC is set, the
>> containing the directory of the trigger file does not exist yet.  This
>> is currently not an error.  The problem only happens if after the GUC is
>> set the containing directory appears and is not readable.
> True, if the hook just consists of trying fopen() and checking the
> errno.  Would it be feasible to insist that the containing directory
> exist and be readable?  We have enough infrastructure that that
> should only take a few lines of code, so the question is whether
> or not that's a nicer behavior than we have now.

Is it possible to do this in a mostly bullet-proof way?  Just because 
the directory exists and looks pretty good otherwise, doesn't mean we 
can read a file created in it later in a way that doesn't fall afoul of 
the existing error checks.  There could be something like SELinux 
lurking, for example.

Maybe some initial checking would be useful, but I think we still need 
to downgrade the error check at use time a bit to not crash in the cases 
that we miss.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


В списке pgsql-hackers по дате отправления
От: Guram Duka
Дата:
От: Eugen Konkov
Дата:
FAQ