Re: Re: [RFC] Shouldn't we remove annoying FATAL messages from server log? - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?
Date
Msg-id 20131205204512.GD6777@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?
List pgsql-hackers
Josh Berkus wrote:

> 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.

My proposal was to have something separate from message severity
("criticality").  So the problems would continue to be reported as
FATAL, ERROR or WARNING, but if they are just the result of something
the user did wrong, then they get marked as "non critical", but if
there, say, a failure to flush xlog (which currently results in an
ERROR), we could flag it as critical.  Grepping the log for critical
messages, regardless of severity, would result in actual action items
for the DBA, without having to grep things out by regex.

Otherwise you have to come up with a lot of messages each keeping the
current behavior of abort the current transaction or not, or terminate
the process or not.

There was also the idea that this would be driven off SQLSTATE but this
seems pretty unwieldy to me.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Why we are going to have to go DirectIO
Next
From: Dean Rasheed
Date:
Subject: Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist