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
>
At Wed, 4 Dec 2019 11:52:33 +0100, Peter Eisentraut
wrote in
> 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 n
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 aft
Peter Eisentraut writes:
> On 2019-11-15 19:23, Tom Lane wrote:
>> If we add a GUC-check-hook test, then the problem of misconfiguration
>> is reduced to the previously unsolved problem that we have crappy
>> feedback for erroneous on-the-fly configuration changes. So it's
>> still unsolved, but
On 2019-11-15 19:23, Tom Lane wrote:
Peter Eisentraut writes:
Say you want to set up promote_trigger_file to point to a file outside
of the data directory, maybe because you want to integrate it with some
external tooling. So you go into your configuration and set
promote_trigger_file =
Alvaro Herrera writes:
> On 2019-Nov-15, Tom Lane wrote:
>> If we add a GUC-check-hook test, then the problem of misconfiguration
>> is reduced to the previously unsolved problem that we have crappy
>> feedback for erroneous on-the-fly configuration changes. So it's
>> still unsolved, but at leas
On 2019-Nov-15, Tom Lane wrote:
> If we add a GUC-check-hook test, then the problem of misconfiguration
> is reduced to the previously unsolved problem that we have crappy
> feedback for erroneous on-the-fly configuration changes. So it's
> still unsolved, but at least we've got one unsolved prob
Peter Eisentraut writes:
> Say you want to set up promote_trigger_file to point to a file outside
> of the data directory, maybe because you want to integrate it with some
> external tooling. So you go into your configuration and set
> promote_trigger_file = '/srv/foobar/trigger'
> and rel
Hello
> Maybe we need a new elevel category for that.
> SYSTEM_WARNING or LOG_WARNING, perhaps?
I think a separate levels for user warnings and system warnings (and errors)
would be great for log analytics. Error due to user typo in query is not the
same as cache lookup error (for example).
re
Fujii Masao writes:
> On Fri, Nov 15, 2019 at 10:49 AM Michael Paquier 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
On 2019-11-15 03:14, Fujii Masao wrote:
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
On Fri, Nov 15, 2019 at 10:49 AM Michael Paquier wrote:
>
> 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 postm
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 rep
Peter Eisentraut writes:
> I have seen the error
> could not stat promote trigger file "...": Permission denied
> because of a misconfiguration (for example, setting promote_trigger_file
> to point into a directory to which you don't have appropriate read or
> execute access).
> The proble
On Thu, Nov 14, 2019 at 10:58 PM Peter Eisentraut
wrote:
>
> I have seen the error
>
> could not stat promote trigger file "...": Permission denied
>
> because of a misconfiguration (for example, setting promote_trigger_file
> to point into a directory to which you don't have appropriate read
I have seen the error
could not stat promote trigger file "...": Permission denied
because of a misconfiguration (for example, setting promote_trigger_file
to point into a directory to which you don't have appropriate read or
execute access).
The problem is that because this happens in t
16 matches
Mail list logo
