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

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

In response to

Responses

Browse pgsql-hackers by date

  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"