From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: could not stat promote trigger file leads to shutdown |
Date: | 2019-11-15 01:49:41 |
Message-ID: | 20191115014941.GC1849@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-11-15 02:08:16 | Re: Ought to use heap_multi_insert() for pg_attribute/depend insertions? |
Previous Message | Michael Paquier | 2019-11-15 01:34:49 | Re: [PATCH] Do not use StdRdOptions in Access Methods |