Re: proposal: additional error fields - Mailing list pgsql-hackers

From Tom Lane
Subject Re: proposal: additional error fields
Date
Msg-id 12156.1335880549@sss.pgh.pa.us
Whole thread Raw
In response to Re: proposal: additional error fields  (Peter Geoghegan <peter@2ndquadrant.com>)
Responses Re: proposal: additional error fields
List pgsql-hackers
Peter Geoghegan <peter@2ndquadrant.com> writes:
> Currently the following informal categories of error are bunched
> together at ERROR severity:

> * Integrity constraint violations
> * Very serious situations, like running out of disk space
> * Serious disasters that often relate to hardware failure, like "xlog
> flush request %X/%X is not satisfied --- flushed only to %X/%X"
> * Errors that if seen relate to a bug within PostgreSQL, with obscure
> error messages, as from most of the elog calls within the planner, for
> example.

> 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.

The last time you complained about this I suggested that looking at
SQLSTATE would resolve most of your concern.  Have you pursued that
angle?

I'm not at all excited about inventing more kinds of "error" severity.
For one thing, the fact that ERROR is the only severity level that
results in a longjmp is known in more places than you might think,
not all of them in the core code.  For another, this would result in a
protocol break -- that is, an incompatibility, not just more fields --
in the FE/BE ErrorResponse message.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Future In-Core Replication
Next
From: Robert Haas
Date:
Subject: extending relations more efficiently