From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Re: [RFC] Shouldn't we remove annoying FATAL messages from server log? |
Date: | 2013-12-05 19:02:09 |
Message-ID: | 52A0CDB1.8000307@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-12-05 19:07:39 | Re: shared memory message queues |
Previous Message | Tom Lane | 2013-12-05 18:52:09 | Re: Regression tests failing if not launched on db "regression" |