MauMau wrote
> From: "Tom Lane" <


> >
>> There is no enthusiasm for a quick-hack solution here, and most people
>> don't actually agree with your proposal that these errors should never
>> get logged.  So no, that is not happening.  You can hack your local
>> copy that way if you like of course, but it's not getting committed.
> Oh, I may have misunderstood your previous comments.  I got the impression 
> that you and others regard those messages (except "too many clients") as 
> unnecessary in server log.
> 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
> 5. FATAL:  terminating walreceiver process due to administrator command
> 6. FATAL:  terminating background worker \"%s\" due to administrator
> command
> Could you tell me why these are necessary in server log?  I guess like
> this. 
> Am I correct?
> * #1 through #3 are necessary for the DBA to investigate and explain to
> the 
> end user why he cannot connect to the database.
> * #4 and #5 are unnecessary for the DBA.  I can't find out any reason why 
> these are useful for the DBA.

For me 1-3 are unusual events in production situations and so knowing when
they occur, and confirming they occurred for a good reason, is a key job of
the DBA.

5 and 6: I don't fully understand when they would happen but likely fall
into the same "the DBA should know what is going on with their server and
confirm any startup/shutdown activity it is involved with".

They might be better categorized "NOTICE" level if they were in response to
a administrator action, versus in response to a crashed process, but even
for the user-initiated situation making sure they hit the log but using
FATAL is totally understandable and IMO desirable.

I'd ask in what situations are these messages occurring so frequently that
they are becoming noise instead of useful data?  Sorry if I missed your
use-case explanation up-thread.

David J.

View this message in context:
Sent from the PostgreSQL - hackers mailing list archive at

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to