Re: proposal: additional error fields

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: additional error fields
Date: 2012-05-01 13:55:49
Message-ID: 12156.1335880549@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Geoghegan <peter(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-05-01 14:08:27 extending relations more efficiently
Previous Message Simon Riggs 2012-05-01 13:35:18 Re: Future In-Core Replication