Re: Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?
От | Josh Berkus |
---|---|
Тема | Re: Re: [RFC] Shouldn't we remove annoying FATAL messages from server log? |
Дата | |
Msg-id | 52A0CDB1.8000307@agliodbs.com обсуждение исходный текст |
Ответ на | [RFC] Shouldn't we remove annoying FATAL messages from server log? ("MauMau" <maumau307@gmail.com>) |
Ответы |
Re: Re: [RFC] Shouldn't we remove annoying FATAL messages
from server log?
Re: Re: [RFC] Shouldn't we remove annoying FATAL messages from server log? Re: Re: [RFC] Shouldn't we remove annoying FATAL messages from server log? |
Список | pgsql-hackers |
On 12/05/2013 10:46 AM, Tom Lane wrote: > Before we could get very far we'd need a better understanding than we have > of what cases a DBA might be interested in. To take the specific example > that started this thread, there wouldn't be a lot of value IMO in a > classification like "connection failure messages". I think the OP is > probably right that those are often uninteresting --- but as I mentioned, > "too many clients" might become interesting if he's wondering whether he > needs to enlarge max_connections. Or password failure cases might become > interesting if he starts to suspect breakin attempts. So I'd want to see > a design that credibly covers those sorts of needs before we put any large > effort into code changes. Heck, I'd be happy just to have a class of messages which specifically means "OMG, there's something wrong with the server", that is, a flag for messages which only occur when PostgreSQL encounters a bug, data corrpution, or platform error. Right now, I have to suss those out by regex. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
В списке pgsql-hackers по дате отправления: