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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers