Re: could not stat promote trigger file leads to shutdown

On 2019-11-15 19:23, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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