From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: could not stat promote trigger file leads to shutdown |
Date: | 2019-12-04 10:52:33 |
Message-ID: | fa103866-894e-a2bc-067d-0d590d6fb7a0@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2019-11-20 16:21, Tom Lane wrote:
>> 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.
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.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Eugen Konkov | 2019-12-04 11:37:57 | Re: Does 'instead of delete' trigger support modification of OLD |
Previous Message | Guram Duka | 2019-12-04 10:32:14 | Re: [PATCH] Fix PostgreSQL 12.1 server build and install problems under MSYS2 |