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.
To be clear, from the client standpoint it's certainly fatal, but not
from the server's point of view. This is fully expected behavior as far
as the server is concerned. (Obviously it might be an error that caused
the shutdown/recovery, but that's something different.)
Right, but as already pointed out in this thread, these messages are
worded from the client's point of view. "The client never got a working
connection" seems to me to be an empty distinction. If you got SIGTERM'd
before you could issue your first query, should that not be FATAL because
you'd not gotten any work done?
More generally, we also say FATAL for all sorts of entirely routine
connection failures, like wrong password or mistyped user name. People
don't seem to have a problem with those. Even if some do complain,
the costs of changing that behavior after fifteen-years-and-counting
would certainly exceed any benefit.
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 to be worried about that FATAL
message? He didn't do anything wrong.
I thought adding "options='-c log_min_messages=PANIC'" to the connection
string for PQping() in pg_ctl.c would vanish the message, but it didn't.
The reason is that connection options take effect in PostgresMain(), which
is after checking the FATAL condition in ProcessStartupPacket(). Do you
think there is any good solution?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
