From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | MauMau <maumau307(at)gmail(dot)com>, Jim Nasby <jim(at)nasby(dot)net>, Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [RFC] Shouldn't we remove annoying FATAL messages from server log? |
Date: | 2013-12-11 18:49:00 |
Message-ID: | 614.1386787740@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2013-12-11 18:49:43 | Re: Completing PL support for Event Triggers |
Previous Message | Robert Haas | 2013-12-11 18:47:48 | Re: -d option for pg_isready is broken |