Re: "unexpected EOF" messages
От | Magnus Hagander |
---|---|
Тема | Re: "unexpected EOF" messages |
Дата | |
Msg-id | CABUevExcaV==jbyaHhhFJMH_YkXC813nsGPmwQs9da=e3YnHwQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: "unexpected EOF" messages (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: "unexpected EOF" messages
Re: "unexpected EOF" messages |
Список | 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 по дате отправления: