Re: could not stat promote trigger file leads to shutdown

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

True, if the hook just consists of trying fopen() and checking the
errno. Would it be feasible to insist that the containing directory
exist and be readable? We have enough infrastructure that that
should only take a few lines of code, so the question is whether
or not that's a nicer behavior than we have now.

If we had this to do over, I'd argue that we misdesigned trigger
files: they should be required to exist always, and triggering
depends on file contents (eg empty vs. not) not existence. That
would make it far easier to check for configuration mistakes
at startup. But I suppose it's too late now.

> We don't have any GUC check hooks on other file system location string
> settings that ensure accessibility or presence of the file.

Right, but I'm suggesting we should add that where appropriate.
Basically the complaint here is that the system lacks checks
that the given configuration settings are workable, and we ought
to add such.

> Although I
> do notice that we use check_canonical_path() in some places and not
> others for mysterious and undocumented reasons.

Probably only that some patch authors didn't know about it :-(

regards, tom lane