Tom Lane-2 wrote
> "MauMau" <
> maumau307@
> > writes:
>> Shouldn't we lower the severity or avoiding those messages to server log?
>
> No. They are FATAL so far as the individual session is concerned.
> Possibly some documentation effort is needed here, but I don't think
> any change in the code behavior would be an improvement.
>
>> 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.)
>
> The notion that a DBA should not be allowed to find out how often #4 is
> happening is insane.
Agreed #4 is definitely DBA territory.
ISTM that instituting some level of categorization for messages would be
helpful. Then logging and reporting frameworks would be able to identify
and segregate the logs in whatever way they and the configuration deems
appropriate.
FATAL: [LOGON] too many clients already
I'd make the category output disabled by default for a long while then
eventually enabled by default but leave the ability to disable. Calls that
do not supply a category get [N/A] output in category mode.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/RFC-Shouldn-t-we-remove-annoying-FATAL-messages-from-server-log-tp5781899p5781925.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.