Re: "unexpected EOF" messages - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: "unexpected EOF" messages
Date
Msg-id CABUevExcaV==jbyaHhhFJMH_YkXC813nsGPmwQs9da=e3YnHwQ@mail.gmail.com
Whole thread Raw
In response to Re: "unexpected EOF" messages  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: "unexpected EOF" messages
Re: "unexpected EOF" messages
List pgsql-hackers
On Thu, May 3, 2012 at 4:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Thu, May 3, 2012 at 4:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I agree with Simon --- a disable for that specific message seems like a
>>> kluge, and an ugly one at that.  (The right solution for this customer
>>> is to fix their broken application.)  But a generic filter capability
>>> might be useful enough to justify its keep.
>
>> Are you thinking basically "regexp against the main text", or
>> something else, when you say "generic filter capacity"?
>
> In the context of yesterday's discussions, I wonder whether a filter by
> SQLSTATE would be appropriate.

I'm worried it's not really granular enough.

regexp-on-text would also have the advantage of being able to filter
stuff coming from stored procedures or such as well - without having
to invent a whole bunch of SQLSTATEs to put in the stored procedures
(consider the usecase when somebody else wrote the stored procedures
and the DBA wants to limit the logging).

We could have two parameters of course - log_filter_sqlstate and
log_filter_re or something like that...

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: How hard would it be to support LIKE in return declaration of generic record function calls ?
Next
From: Bruce Momjian
Date:
Subject: Re: remove dead ports?