Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?
Дата
Msg-id 614.1386787740@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?  (Josh Berkus <josh@agliodbs.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: -d option for pg_isready is broken
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Completing PL support for Event Triggers