Re: proposal: additional error fields

On 1 May 2012 14:55, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> The last time you complained about this I suggested that looking at
> SQLSTATE would resolve most of your concern.  Have you pursued that
> angle?

Sure, I did consider that at the time.

I think that a new severity level (equivalent to ERROR in all but
name) is warranted to make a representation that certain errors are
more severe than the bulk of ERRORs seen in real production systems,
that do not warrant being treated as FATAL or PANIC. Leaving aside the
practical implications, it seems likely that many will agree that a
new severity level is at least intuitively the most natural way to do
so. Another consideration is that it seems unlikely that many elog
call sites will ever be replaced by ereport calls, that specify an
SQLSTATE . As it says in the docs:

"Any message that is likely to be of interest to ordinary users should
go through ereport. Nonetheless, there are enough internal "can't
happen" error checks in the system that elog is still widely used; it
is preferred for those messages for its notational simplicity."

Certainly, the "xlog flush request not satisfied" example is a simple
elog call, as are many other bellwethers of data corruption.

What if the user doesn't specify %e in their log_line_prefix (most
don't)? What hope have they then? You might counter "they can add that
if they're interested", but who isn't interested in nipping serious
problems in the bud? Yes, we ought to be somewhat paternalistically
forcing users to take notice of severe problems by drawing their
attention to them using special terminology. Besides, SQLSTATE doesn't
attempt to classify errors by severity, but merely characterises them
as belonging to some subsystem, or some broad category of error. Sure,
some of these are unambiguously serious, like disk_full or
data_corrupted, but others clearly straddle between being errors and
severe errors, like internal_error. Besides, who wants to go to the
trouble of enumerating all known severe SQLSTATE codes when grepping
for such a simple requirement?

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

I don't think that bumping the protocol version is necessarily that
big of a deal. Certainly, it wouldn't be very difficult to make the
new version of the protocol compatible with the old - SEVERE_ERROR
will simply act as an alias for ERROR there.

Maybe no one is convinced by any of this, but the fact is that the
SQLSTATE argument falls down when one considers that we aren't using
it in many cases of errors that clearly are severe. I draw a very
strong practical distinction between errors that are a serious
problem, that I need to worry about, and errors that are routine. To
my mind it's a pity that Postgres doesn't similarly draw this
distinction, even if that does imply that there will be a certain
amount of grey area.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services