From: Kevin Grittner kgri...@ymail.com
It seems to be a fairly common term of art for a problem which
requires a restart or reconnection. FATAL is used when the problem
is severe enough that the process or connection must end. It seems
to me to be what should consistently be used when a client
On 2013-12-12 00:31:25 +0900, MauMau wrote:
What do you think of #5 and #6 when matching the above criteria?
5. FATAL: terminating walreceiver process due to administrator command
6. FATAL: terminating background worker \%s\ due to administrator command
Those are important if they happen
MauMau maumau...@gmail.com wrote:
From: Kevin Grittner kgri...@ymail.com
FATAL is used when the problem is severe enough that the process
or connection must end. It seems to me to be what should
consistently be used when a client connection or its process must
be terminated for a reason
From: Tom Lane t...@sss.pgh.pa.us
Jim Nasby j...@nasby.net writes:
On 12/9/13 5:56 PM, Tom Lane wrote:
How so? FATAL means an error that terminates your session, which
is exactly what these are.
Except in these cases the user never actually got a working session;
their request was denied.
MauMau maumau...@gmail.com writes:
I agree that #1-#3 are of course reasonable when there's any client the user
runs. The problem is that #1 (The database system is starting up) is output
in the server log by pg_ctl. In that case, there's no client the user is
responsible for. Why does a
From: Andres Freund and...@2ndquadrant.com
On 2013-12-12 00:31:25 +0900, MauMau wrote:
5. FATAL: terminating walreceiver process due to administrator command
6. FATAL: terminating background worker \%s\ due to administrator
command
Those are important if they happen outside a shutdown. So,
From: Kevin Grittner kgri...@ymail.com
5. FATAL: terminating walreceiver process due to administrator
command
6. FATAL: terminating background worker \%s\ due to
administrator command
Those are client connections and their backends terminated for a
reason other than the client side of the
On 12/11/2013 08:48 AM, Tom Lane wrote:
The fundamental problem IMO is that you want to complicate the definition
of what these things mean as a substitute for DBAs learning something
about Postgres. That seems like a fool's errand from here. They're going
to have to learn what FATAL means
Josh Berkus j...@agliodbs.com writes:
However, it would really be useful to have an extra tag (in addition to
the ERROR or FATAL) for If you're seeing this message, something has
gone seriously wrong on the server. Just stuff like corruption
messages, backend crashes, etc.
Right, we've
MauMau maumau...@gmail.com wrote:
From: Greg Stark st...@mit.edu
On the client end the FATAL is pretty logical but in the logs it
makes it sound like the entire server died.
I agree that is easily misunderstood, especially since a FATAL
problem is less severe than a PANIC; while in common
On 12/6/13 7:38 AM, Andres Freund wrote:
On 2013-12-06 22:35:21 +0900, MauMau wrote:
From: Tom Lane t...@sss.pgh.pa.us
No. They are FATAL so far as the individual session is concerned.
Possibly some documentation effort is needed here, but I don't think
any change in the code behavior would
Jim Nasby j...@nasby.net writes:
Arguably 1-3 are inaccurate since they're not really about a backend dying...
they occur during the startup phase; you never even get a functioning
backend. That's a marked difference from other uses of FATAL.
How so? FATAL means an error that terminates
On 12/9/13 5:56 PM, Tom Lane wrote:
Jim Nasby j...@nasby.net writes:
Arguably 1-3 are inaccurate since they're not really about a backend dying...
they occur during the startup phase; you never even get a functioning backend.
That's a marked difference from other uses of FATAL.
How so?
Jim Nasby j...@nasby.net writes:
On 12/9/13 5:56 PM, Tom Lane wrote:
How so? FATAL means an error that terminates your session, which
is exactly what these are.
Except in these cases the user never actually got a working session; their
request was denied.
To be clear, from the client
On 12/05/2013 11:25 PM, MauMau wrote:
Hello,
My customers and colleagues sometimes (or often?) ask about the
following message:
FATAL: the database system is starting up
I would LOVE that message to do away, forever.
It's a huge PITA for automated log monitoring, analysis, and alerting.
On Tue, Dec 10, 2013 at 08:47:22AM +0800, Craig Ringer wrote:
On 12/05/2013 11:25 PM, MauMau wrote:
Hello,
My customers and colleagues sometimes (or often?) ask about the
following message:
FATAL: the database system is starting up
I would LOVE that message to do away, forever.
From: Greg Stark st...@mit.edu
On the client end the FATAL is pretty logical but in the logs it makes
it sound like the entire server died. Especially in this day of
multithreaded servers. I was suggesting that that was the origin of
the confusion here. Anyone who has seen these messages on the
On Sat, Dec 7, 2013 at 12:27 AM, David Johnston pol...@yahoo.com wrote:
1. FATAL: the database system is starting up
How about altering the message to tone down the severity by a half-step...
FATAL: (probably) not! - the database system is starting up
Well it is fatal, the backend for that
On 2013-12-07 13:58:11 +, Greg Stark wrote:
FATAL means a backend died. It is kind of vague how FATAL and PANIC
differ.
I don't really see much vagueness there. FATAL is an unexpected but
orderly shutdown. PANIC is for the situations where we can't handle the
problem that occurred in any
On Sat, Dec 7, 2013 at 3:56 PM, Andres Freund and...@2ndquadrant.com wrote:
I don't really see much vagueness there. FATAL is an unexpected but
orderly shutdown. PANIC is for the situations where we can't handle the
problem that occurred in any orderly way.
Sorry, I was unclear. I meant that
From: Peter Eisentraut pete...@gmx.net
Yeah, this is part of a more general problem, which you have
characterized correctly: What is fatal (or error, or warning, ...) to
the client isn't necessarily fatal (or error, or warning, ...) to the
server or DBA.
Thanks. In addition, #5 and #6 in my
From: Tom Lane t...@sss.pgh.pa.us
No. They are FATAL so far as the individual session is concerned.
Possibly some documentation effort is needed here, but I don't think
any change in the code behavior would be an improvement.
You are suggesting that we should add a note like Don't worry about
On 2013-12-06 22:35:21 +0900, MauMau wrote:
From: Tom Lane t...@sss.pgh.pa.us
No. They are FATAL so far as the individual session is concerned.
Possibly some documentation effort is needed here, but I don't think
any change in the code behavior would be an improvement.
You are suggesting
Hello,
My customers and colleagues sometimes (or often?) ask about the following
message:
FATAL: the database system is starting up
This message is often output dozens of times during a failover or PITR. The
users seem to be worried because the message level is FATAL and they don't
know
On 12/5/13, 10:25 AM, MauMau wrote:
Report these as FATAL to the client because the client wants to know the
reason. But don't output them to server log because they are not
necessary for DBAs
Yeah, this is part of a more general problem, which you have
characterized correctly: What is fatal
MauMau maumau...@gmail.com writes:
Shouldn't we lower the severity or avoiding those messages to server log?
No. They are FATAL so far as the individual session is concerned.
Possibly some documentation effort is needed here, but I don't think
any change in the code behavior would be an
26 matches
Mail list logo
