Re: could not stat promote trigger file leads to shutdown

Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
> On Fri, Nov 15, 2019 at 10:49 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>> On Thu, Nov 14, 2019 at 10:38:30AM -0500, Tom Lane wrote:
>>> (BTW, from this perspective, WARNING is especially bad because it
>>>> might not get logged at all. Better to use LOG.)

>> Neither am I comfortable with that.

> I always wonder why WARNING was defined that way.
> I think that users usually pay attention to the word "WARNING"
> rather than "LOG".

The issue really is "what are we warning about". The way things
are set up basically assumes that WARNING is for complaining about
user-issued commands that might not be doing what the user wants.
Which is a legitimate use-case, but it doesn't necessarily mean
something that's very important to put in the postmaster log.

What we're seeing, in these repeated proposals to use WARNING in
some background process that doesn't run user commands, is that
there is also a use-case for "more-significant-than-usual log
messages". Maybe we need a new elevel category for that.
SYSTEM_WARNING or LOG_WARNING, perhaps?

>> I think that we could do something close to the area where
>> RemovePromoteSignalFiles() gets called. Why not simply checking the
>> path defined by PromoteTriggerFile() at startup time then? I take it
>> that the only thing we should not complain about is stat() returning
>> ENOENT when looking at the promote file defined.

> promote_trigger_file is declared as PGC_SIGHUP,
> so such check would be necessary even while the standby is running.
> Which can cause the server to fail after the startup.

No, it'd be just the same as any other GUC: if we make such a test
in the check hook, then we'd fail for a bad value at startup, but
at SIGHUP we'd just reject the new setting. I think this might be
a workable answer to Peter's concern.

regards, tom lane