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 20200519061313.GD11835@paquier.xyz
Whole thread Raw
In response to Re: could not stat promote trigger file leads to shutdown  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On Wed, Dec 04, 2019 at 11:52:33AM +0100, Peter Eisentraut wrote:
> Is it possible to do this in a mostly bullet-proof way?  Just because the
> directory exists and looks pretty good otherwise, doesn't mean we can read a
> file created in it later in a way that doesn't fall afoul of the existing
> error checks.  There could be something like SELinux lurking, for example.
>
> Maybe some initial checking would be useful, but I think we still need to
> downgrade the error check at use time a bit to not crash in the cases that
> we miss.

I got that thread in my backlog for some time, and was not able to
come back to it.  Reading it again the thread, it seems to me that
using a LOG would make the promote file handling more consistent with
what we do for the SSL context reload.  Still, one downside I can see
here is that this causes the backend to create a new LOG entry each
time the promote file is checked, aka each time we check if WAL is
available.  Couldn't that bloat be a problem?  During the SSL reload,
we only generate LOG entries for each backend on SIGHUP.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Missing grammar production for WITH TIES
Next
From: Laurenz Albe
Date:
Subject: Re: Add A Glossary