Re: proposal: additional error fields

On 1 May 2012 22:09, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> 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.

I doubt that opinion would be that widely divided, and in any case I
see no reason to let the perfect be the enemy of the good. For example
Tom seemed pretty confident that the definition of
non-routine/critical could be "has one of a limited number of existing
SQLSTATEs", assuming use of elogs is formally limited to "can't
happen" errors...

> So it would be best if it was configurable.

...that said, it could be configurable, if the case for that were
argued convincingly. At the very least, I'd expect the vast majority
of users to stick to a stock set of SQLSTATEs.

> 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 accept the premise that absolutely anything that could be done
outside of the core system should not be in the core system. By that
standard you could argue that a great deal of existing features
shouldn't have been accepted, including for example streaming
replication, since external systems provide roughly equivalent, albeit
non-standardised, in some ways inferior behaviour (doing this in some
third party project certainly isn't exactly equivalent, since there is
no way to put the magnitude of the message in log_line_prefix to have
it directly readable by a human from the logfile, etc).

The pertinent question to my mind isn't whether we could do this
outside the server, but rather if we *should* do it within the server.
I think that we should, because lots of people want to know if their
database server has our best working definition of a serious problem.
That isn't a narrow use-case.

There is another advantage to doing this within the core system that I
have not touched upon, which is that in this way we can expose another
useful GUC to reduce log noise, beyond log_min_messages. It's
certainly not inconceivable that smaller sites could find it useful to
not have to log every single integrity constraint violation, while
still seeing other types of errors.

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