Re: proposal: additional error fields

Excerpts from Noah Misch's message of mar may 01 15:36:22 -0400 2012:
> On Tue, May 01, 2012 at 02:19:16PM +0100, Peter Geoghegan wrote:

> > The first category of error is something that the DBA will often see
> > very frequently. The latter 3 are situations which I'd like to be
> > woken up in the middle of the night to respond to. We ought to be
> > facilitating monitoring tools (including very simple ones like grep),
> > so that they can make this very important practical distinction. The
> > hard part is replacing the severity level of many existing
> > elog/ereport call sites, but that's not much of a problem, really.
>
> 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.

So maybe a new severity is not the answer -- perhaps a separate error
data field, say "criticality" (just to give it a name). ereport() could
be labeled by default with routine (low) criticality, or a new macro
errcritical(ERRCRIT_HIGH) could set it higher (which we would introduce
manually in the right places); while elog() would have high criticality
by default except for DEBUG messages (maybe we'd need a new macro
elog_routine() for messages with a higher severity than DEBUG that do
not need to be marked as critical).

So in the log we could end up with noncritical messages being displayed
as today, and critical ones with a new tag:

FATAL: terminating connection due to conflict with recovery
FATAL: CRITICAL: incorrect checksum in control file

or something like that.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support