17.01.2014 19:07, Tom Lane kirjoitti:
Oskari Saarenmaa writes:
I don't know about others, but filtering by individual SQLSTATE is
exactly what I need - I don't want to suppress all plpgsql errors or
constraint violations, but I may want to suppress plpgsql RAISE
EXCEPTION and CHECK violations.
30.01.2014 11:37, Jeevan Chalke kirjoitti:
Hi Oskari,
Are you planning to work on what Tom has suggested ? It make sense to me
as well.
What are your views on that ?
Tom's suggestions make sense to me, but unfortunately I haven't had time
to work on this feature recently so I don't think it'
Hi Oskari,
Are you planning to work on what Tom has suggested ? It make sense to me as
well.
What are your views on that ?
Thanks
--
Jeevan B Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
Oskari Saarenmaa writes:
> 17.01.2014 00:13, Tom Lane kirjoitti:
>> I find it hard to follow exactly what the use-case for this is; could
>> you make a defense of why we should carry a feature like this?
> I usually run PG with log_min_messages = warning and
> log_min_error_statement = error to
17.01.2014 00:13, Tom Lane kirjoitti:
Oskari Saarenmaa writes:
[ 0001-Filter-error-log-statements-by-sqlstate.patch ]
I looked at this patch. It took me some time to understand that what
it actually does has got approximately nothing to do with what one might
first expect: rather than suppre
Please fix the compiler warning:
elog.c: In function ‘check_log_sqlstate_error’:
elog.c:3789:41: warning: ‘new_newval_end’ may be used uninitialized in
this function [-Wuninitialized]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
htt
Oskari Saarenmaa writes:
> [ 0001-Filter-error-log-statements-by-sqlstate.patch ]
I looked at this patch. It took me some time to understand that what
it actually does has got approximately nothing to do with what one might
first expect: rather than suppressing the entire log message about some
Hi Oskari,
Patch looks good to me now. I have found no issues too. It is good to go in
now.
However, few small suggestions:
1. Whenever we know that a variable is containing only 32 bits, better
define
it as uint32 and not just int (m_sqlstate in get_sqlstate_error_level()
function). int size ma
On Tue, Jan 14, 2014 at 12:22:30PM +0530, Jeevan Chalke wrote:
> On Mon, Jan 13, 2014 at 4:30 PM, Oskari Saarenmaa wrote:
> > On 13/01/14 10:26, Jeevan Chalke wrote:
> >
> > > 1. Documentation is missing and thus becomes difficult to understand
> > > what exactly you are trying to do. Or in other
On Mon, Jan 13, 2014 at 4:30 PM, Oskari Saarenmaa wrote:
> Hi,
>
>
> On 13/01/14 10:26, Jeevan Chalke wrote:
>
>> 1. Documentation is missing and thus becomes difficult to understand what
>> exactly you are trying to do. Or in other words, user will be uncertain
>> about using it more efficiently
Hi,
On 13/01/14 10:26, Jeevan Chalke wrote:
1. Documentation is missing and thus becomes difficult to understand what
exactly you are trying to do. Or in other words, user will be uncertain
about using it more efficiently.
I figured I'd write documentation for this if it looks like a useful
f
Hi Oskari,
I had a quick look over the patch (Not compiled though). Here are few
comments on the changes:
1. Documentation is missing and thus becomes difficult to understand what
exactly you are trying to do. Or in other words, user will be uncertain
about
using it more efficiently.
2. Some more
Allow the default log_min_error_statement to be overridden per sqlstate
to make it possible to filter out some error types while maintaining a
low log_min_error_statement or enable logging for some error types when
the default is to not log anything.
I've tried to do something like this using
13 matches
Mail list logo
