On 1 May 2012 14:01, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> What I'd also like to see, which is
>> something that I've agitated about in the past without much luck, is
>> for a new severity level, along the lines of a "severe error". The
>> idea of this is to make a representation that the error in question is
>> one that the DBA should reasonably hope to never see. That is quite
>> distinct from the nature of what usually form the large majority of
>> errors - routine integrity constraint violations and things like that.
>> Do you suppose you could incorporate this into your design?
>
> I don't understand well, can you explain it.
Alright. Table 18-1 describes current severity levels:
http://www.postgresql.org/docs/current/static/runtime-config-logging.html#RUNTIME-CONFIG-SEVERITY-LEVELS
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.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services