Re: could not stat promote trigger file leads to shutdown

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: could not stat promote trigger file leads to shutdown
Дата
Msg-id e6aac026-174c-9952-689f-6bee76f9ab68@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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2019-11-15 19:23, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> Say you want to set up promote_trigger_file to point to a file outside
>> of the data directory, maybe because you want to integrate it with some
>> external tooling.  So you go into your configuration and set
>>       promote_trigger_file = '/srv/foobar/trigger'
>> and reload the server.  Everything is happy.  The fact that the
>> directory /srv/foobar/ does not exist at this point is completely ignored.
>> Now you become root and run
>>       mkdir /srv/foobar
>> and, depending circumstances such as root's umask or the permissions of
>> /srv, your PostgreSQL server crashes immediately.  That can't be good.
> 
> No, it's not good, but the proposed fix of s/ERROR/LOG/ simply delays
> the problem till later, ie when you try to promote the server nothing
> happens.  That's not good either.  (To be clear: I'm not necessarily
> against that change, I just don't think it's a sufficient response.)
> 
> If we add a GUC-check-hook test, then the problem of misconfiguration
> is reduced to the previously unsolved problem that we have crappy
> feedback for erroneous on-the-fly configuration changes.  So it's
> still unsolved, but at least we've got one unsolved problem not two.

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.

I notice that we use LOG level if an SSL key or certificate file is not 
accessible on reload, so that seems somewhat similar.

We don't have any GUC check hooks on other file system location string 
settings that ensure accessibility or presence of the file.  Although I 
do notice that we use check_canonical_path() in some places and not 
others for mysterious and undocumented reasons.

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



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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] Block level parallel vacuum
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: [HACKERS] WAL logging problem in 9.4.3?