Josh Berkus 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 discussed that id
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 mean
From: "Kevin Grittner"
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 connection request
From: "Andres Freund"
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, if you really
want
"MauMau" 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 new DBA have
From: "Tom Lane"
Jim Nasby 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 cli
MauMau wrote:
> From: "Kevin Grittner"
> 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 other than a client-side request t
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 hap
From: "Kevin Grittner"
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
connection or its
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 a
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 aler
Jim Nasby 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 standp
On 12/9/13 5:56 PM, Tom Lane wrote:
Jim Nasby 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
Jim Nasby 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 your session
On 12/6/13 7:38 AM, Andres Freund wrote:
On 2013-12-06 22:35:21 +0900, MauMau wrote:
From: "Tom Lane"
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.
MauMau wrote:
> From: "Greg Stark"
>> 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 English usage
panic is what m
From: "Greg Stark"
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 client
end m
On Sat, Dec 7, 2013 at 3:56 PM, Andres Freund 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 without context if
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 o
On Sat, Dec 7, 2013 at 12:27 AM, David Johnston 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 client d
On 2013-12-06 22:35:21 +0900, MauMau wrote:
> From: "Tom Lane"
> >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 s
From: "Tom Lane"
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 the
following
From: "Peter Eisentraut"
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 previous mail a
"MauMau" 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 improvement.
> 1. FATA
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 fata
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 w
26 matches
Mail list logo
