Re: [RFC] Shouldn't we remove annoying FATAL messages from server log? - Mailing list pgsql-hackers

From MauMau
Subject Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?
Date
Msg-id 87C6B43A74ED462782A4AE08743BF833@maumau
Whole thread Raw
In response to Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?  (Kevin Grittner <kgrittn@ymail.com>)
List pgsql-hackers
From: "Kevin Grittner" <kgrittn@ymail.com>
> 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 requesting it.
If we don't classify those as FATAL then the definition of FATAL
becomes much more fuzzy. What would you define it to mean?


I'm sorry to cause you trouble, but my understanding is that those are not 
client connections.  They are just background server processes; walreceiver 
is started by startup process, and background workers are started by 
extension modules.  Am I misunderstanding something?

According to Table 18-1 in the manual:

http://www.postgresql.org/docs/current/static/runtime-config-logging.html

the definition of FATAL is:

FATAL
Reports an error that caused the current session to abort.

This does not apply to the above messages, because there is no error.  The 
DBA just shut down the database server, and the background processes 
terminated successfully.

If some message output is desired, LOG's definition seems the nearest:

LOG
Reports information of interest to administrators, e.g., checkpoint 
activity.

So, I thought "ereport(LOG, ...); proc_exit(0)" is more appropriate than 
ereport(FATAL, ...).  Is this so strange?

Regards
MauMau




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ANALYZE sampling is too good
Next
From: Josh Berkus
Date:
Subject: Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?