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

From Tom Lane
Subject Re: could not stat promote trigger file leads to shutdown
Date
Msg-id 9842.1573842222@sss.pgh.pa.us
Whole thread Raw
In response to Re: could not stat promote trigger file leads to shutdown  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses 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  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] Implement INSERT SET syntax
Next
From: Tom Lane
Date:
Subject: Re: Role membership and DROP