Re: proposal: additional error fields

On 1 May 2012 20:36, Noah Misch <noah(at)leadboat(dot)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