Skip site navigation (1) Skip section navigation (2)

Re: proposal: additional error fields

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Peter Geoghegan" <peter(at)2ndquadrant(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 21:09:56
Message-ID: 4FA00AD4020000250004769E@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
 
> The argument could be made that what I've characterised as severe
> (which is, as I've said, not entirely clear-cut) could be deduced
> from SQLSTATE if we were to formalise the "can't happen errors are
> only allowed to use elog()" convention into a hard rule.
 
That doesn't seem necessary or desirable.  The thing to do is to
somewhere define a list of what is "severe".  It seems likely that
different shops may have different opinions on what constitutes a
"severe" problem, or may have more than a "severe"/"not severe"
dichotomy.  So it would be best if it was configurable.  To solve
the problem, we mostly seem to need something which can scan the
server log and take action based on SQLSTATE values.  Since we can
already easily log those, this seems like territory for external
monitoring software.
 
I don't see anything for the community here other than to discuss
places where we might want to use a different SQLSTATE than we
currently do.  Or possibly hooks in the logging process, so monitors
don't need to scan text.
 
-Kevin

In response to

Responses

pgsql-hackers by date

Next:From: Stephen FrostDate: 2012-05-01 21:15:03
Subject: Re: extending relations more efficiently
Previous:From: Tom LaneDate: 2012-05-01 20:56:43
Subject: Re: port _srv.o makefile rules don't observe dependency tracking

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group