From: "Tom Lane" <tgl@sss.pgh.pa.us>
> Jim Nasby <jim@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
