Re: could not stat promote trigger file leads to shutdown

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: could not stat promote trigger file leads to shutdown
Дата
Msg-id 20200519061313.GD11835@paquier.xyz
обсуждение исходный текст
Ответ на Re: could not stat promote trigger file leads to shutdown  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
On Wed, Dec 04, 2019 at 11:52:33AM +0100, Peter Eisentraut wrote:
> 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.

I got that thread in my backlog for some time, and was not able to
come back to it.  Reading it again the thread, it seems to me that
using a LOG would make the promote file handling more consistent with
what we do for the SSL context reload.  Still, one downside I can see
here is that this causes the backend to create a new LOG entry each
time the promote file is checked, aka each time we check if WAL is
available.  Couldn't that bloat be a problem?  During the SSL reload,
we only generate LOG entries for each backend on SIGHUP.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Missing grammar production for WITH TIES
Следующее
От: Laurenz Albe
Дата:
Сообщение: Re: Add A Glossary