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

From Michael Paquier
Subject Re: could not stat promote trigger file leads to shutdown
Date
Msg-id 20191115014941.GC1849@paquier.xyz
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  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
On Thu, Nov 14, 2019 at 10:38:30AM -0500, Tom Lane wrote:
> It is harsh, but I suspect if we just logged the complaint, we'd get
> bug reports about "Postgres isn't reacting to my trigger file",
> because people don't read the postmaster log unless forced to.
> Is there some more-visible way to report the problem, short of
> shutting down?
>
> (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.

> One thought is to try to detect the misconfiguration at postmaster
> start --- better to fail at startup than sometime later.  But I'm
> not sure how reliably we could do that.

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.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [PATCH] Do not use StdRdOptions in Access Methods
Next
From: Michael Paquier
Date:
Subject: Re: Ought to use heap_multi_insert() for pg_attribute/dependinsertions?