On 1 May 2012 20:36, Noah Misch <n...@leadboat.com> wrote: > I agree that some means to mechanically distinguish these cases would > constitute a significant boon for admin monitoring. Note, however, that the > same split appears at other severity levels: > > FATAL, routine: terminating connection due to conflict with recovery > FATAL, critical: incorrect checksum in control file > WARNING, routine: nonstandard use of escape in a string literal > WARNING, critical: locallock table corrupted > > We'd be adding at least three new severity levels to cover the necessary > messages by this approach.
Good point. It might make sense to have an orthogonal property - call it magnitude - and have that specified alongside the existing severity levels. However, there's really no point in bothering if all of the existing elog calls are let off the hook. Someone would need to go around and assign a value to every existing single elog and ereport callsite, with the exisiting elog macro signature incrementally deprecated. Furthermore, I'd support changing the definition of log_line_prefix within postgresql.conf.sample to include this new property by default. This feature will only be a boon to admin monitoring if it's actually something that there is a reasonable expectation of finding on most or all Postgres production systems in all circumstances. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers