Re: could not stat promote trigger file leads to shutdown - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: could not stat promote trigger file leads to shutdown
Date
Msg-id e6aac026-174c-9952-689f-6bee76f9ab68@2ndquadrant.com
Whole thread Raw
In response to Re: could not stat promote trigger file leads to shutdown  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: could not stat promote trigger file leads to shutdown  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Block level parallel vacuum
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: [HACKERS] WAL logging problem in 9.4.3?