17.01.2014 19:07, Tom Lane kirjoitti:
> Oskari Saarenmaa <os@ohmu.fi> 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.
[...]
> It hasn't really been proven that SQLSTATE-class filtering would work
> conveniently, but AFAICS the only way to prove or disprove that is for
> somebody to code it up and use it in production.
[...]
> Another thought here is that if you're willing to have the filter
> only able to *prevent* logging, and not to let it *cause* logging
> of messages that would otherwise be suppressed by log_min_messages,
> it could be implemented as a loadable module using the emit_log_hook.
So this is what we ended up doing: a module with emit_log_hook to allow
upgrading "log_min_messages" and "log_min_error_statement" values per
sqlstate. I'm now using this in production and it has had a positive
impact in reducing the volume of (unwanted) logs being collected and
allowing a kludgy rsyslog.conf filter to be removed (which didn't really
work that well - it only dropped the first part of a multipart log
entry, writing partial pg log entries in syslog).
https://github.com/ohmu/pgloggingfilter
I'm not super happy about the syntax it uses, but at least it should be
obvious that it works just like the core GUCs but is settable per
sqlstate. I've been planning to sketch a proposal for a better way to
configure log verbosity and details based on sqlstate, statement
duration or other variables, but unfortunately haven't had time to do it
yet.
/ Oskari