Re: [RFC] Shouldn't we remove annoying FATAL messages from server log? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?
Date
Msg-id 614.1386787740@sss.pgh.pa.us
Whole thread Raw
In response to Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
> However, it would really be useful to have an extra tag (in addition to
> the ERROR or FATAL) for "If you're seeing this message, something has
> gone seriously wrong on the server."  Just stuff like corruption
> messages, backend crashes, etc.

Right, we've discussed that idea elsewhere; there's a basically orthogonal
classification that needs to happen.  Pretty much all PANICs are high
priority from a DBA's perspective, but only a subset of either FATAL or
ERROR are.  Somebody needs to do the legwork to determine just what kind
of classification scheme we want and propose at least an initial set of
ereports to be so marked.

One thought I had was that we could probably consider the default behavior
(in the absence of any call of an explicit criticality-marking function)
to be like this:
for ereport(), it's critical if a PANIC and otherwise not
for elog(), it's critical if >= ERROR level, otherwise not.
The rationale for this is that we generally use elog for
not-supposed-to-happen cases, so those are probably interesting.
If we start getting complaints about some elog not being so interesting,
we can convert it to an ereport so it can include an explicit marking
call.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: -d option for pg_isready is broken
Next
From: Peter Eisentraut
Date:
Subject: Re: Completing PL support for Event Triggers