[RFC] Shouldn't we remove annoying FATAL messages from server log?

From: "MauMau" <maumau307(at)gmail(dot)com>
To: <pgsql-hackers(at)postgresql(dot)org>
Subject: [RFC] Shouldn't we remove annoying FATAL messages from server log?
Date: 2013-12-05 15:25:52
Message-ID: F3D7196956AD43A88270FF3FC34E8221@maumau
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 why such severe message is output in a successful failover and
recovery. I can blame the users, because the message is merely a
sub-product of pg_ctl's internal ping.

Similarly, the below message is output when I stop the standby server
normally. Why FATAL as a result of successful operation? I'm afraid DBAs
are annoyed by these messages, as system administration software collects
ERROR and more severe messages for daily monitoring.

FATAL: terminating walreceiver process due to administrator command

Shouldn't we lower the severity or avoiding those messages to server log?
How about the following measures?

1. FATAL: the database system is starting up
2. FATAL: the database system is shutting down
3. FATAL: the database system is in recovery mode
4. FATAL: sorry, too many clients already
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 (4 is subtle.)

5. FATAL: terminating walreceiver process due to administrator command
6. FATAL: terminating background worker \"%s\" due to administrator command
Don't output these to server log. Why are they necessary? For
troubleshooting purposes? If necessary, the severity should be LOG (but I
wonder why other background processes are not reported...)

To suppress server log output, I think we can do as follows. I guess
ereport(FATAL) is still needed for easily handling both client report and
process termination.

log_min_messages = PANIC;
ereport(FATAL,
(errcode(ERRCODE_CANNOT_CONNECT_NOW),
errmsg("the database system is starting up")));

May I hear your opinions?

Regards
MauMau

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-12-05 15:25:54 Re: Proposal: variant of regclass
Previous Message Robert Haas 2013-12-05 15:17:18 Re: same-address mappings vs. relative pointers