Re: proposal: additional error fields - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: additional error fields
Date
Msg-id CAFj8pRCus5NSQDQ=QtTiK_SxFS4AqKDRCBzOfLMKYzvREDPhUw@mail.gmail.com
Whole thread Raw
In response to Re: proposal: additional error fields  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
2012/5/2 Robert Haas <robertmhaas@gmail.com>:
> On Tue, May 1, 2012 at 4:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I continue to maintain that the SQLSTATE is a much better basis for
>> solving this problem.  Its categories are already pretty close to
>> what Peter needs: basically, IIUC, he wants to know about classes
>> 53, 58, maybe F0, and XX.
>
> This is really too mushy, IMHO.  ERRCODE_TOO_MANY_CONNECTIONS isn't
> what I'd call an oh-shit condition even though it's in class 53, but
> this "could not create archive status file \"%s\"" is definitely an
> oh-shit regardless of what errcode_for_file_access() returns.
>
> Also, the fact is that most people do not log SQLSTATEs.  And even if
> they did, they're not going to know to grep for 53|58|maybe F0|XX.
> What we need is an easy way for people to pick out any log entries
> that represent conditions that should never occur as a result of any
> legitimate user activity.  Like, with grep.  And, without needing to
> have a PhD in Postgresology.

long time I wish Pg supports more log files and now I had to write
extension for forwarding slow queries to other log.

so possible solutions can be extension that support mapping,
forwarding, post processing of log items. We have no example for
log_hook still.

Regards

Pavel

>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Have we out-grown Flex?
Next
From: Vivek Singh Raghuwanshi
Date:
Subject: Features of Postgresql and Postgres-xc with MySQL