Re: proposal: additional error fields
От | Kevin Grittner |
---|---|
Тема | Re: proposal: additional error fields |
Дата | |
Msg-id | 4FA00AD4020000250004769E@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: proposal: additional error fields (Peter Geoghegan <peter@2ndquadrant.com>) |
Ответы |
Re: proposal: additional error fields
|
Список | pgsql-hackers |
Peter Geoghegan <peter@2ndquadrant.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
В списке pgsql-hackers по дате отправления: