G Dutton wrote:
> Hello all,
>
> I've seen some rather tangential postings about means of filtering log
> messages, but none quite match up to (what I believe to be) my
> requirement, so here goes:
>
> As a means of auditing our database server, I would like to use the
> PostgreSQL 'log_statement' mechanism. Having set log_statement = 'all' I
> was disappointed to find that statement messages are logged with INFO
> severity, alongside more general operational messages such as shutdown or
> startup.
>
> This means that, even using syslog as a destination, it's not possible for
> me to filter statements without some sort of log-text parsing, which I'd
> prefer to avoid on effort, performance and data-integrity grounds.
>
> For my purposes, I'd like SQL statement logging to be completely separable
> from other forms of logging, so that statements can be set aside for
> several reasons, notably performance (logging the heavy statement traffic
> to another set of spindles or even /dev/shm with rotation to persistent
> storage, for instance) and administrative convenience (to make the human
> portion of the auditing process more straightforward).
>
> The most straightforward way in which I can think to do this, would be to
> make the log_statement syslog (and therefore postgresql) severity
> configurable. Does anyone think that a
>
> # combined with syslog logging destination, statements go to "local0.debug"
> log_statement_severity = <pgsql-severity, e.g. 'debug1'>
>
> configuration parameter is sensible? out of the question? Is it a good
> idea to generalise this even further? Or is there perhaps an alternative
> that I've not considered, for easy and performant redirection of just my
> logged statements?
Our logging system is very flexible, but not work-free on the user end.
I don't see us changing things in that area.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
