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

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?
Date: 2013-12-05 20:45:12
Message-ID: 20131205204512.GD6777@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

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