log_statement and syslog severity - Mailing list pgsql-general

From G Dutton
Subject log_statement and syslog severity
Date
Msg-id alpine.LRH.2.00.1003051637070.10565@kempt.inf.ed.ac.uk
Whole thread Raw
Responses Re: log_statement and syslog severity  (Bruce Momjian <bruce@momjian.us>)
List pgsql-general
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?

Cheers,

Graham

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


pgsql-general by date:

Previous
From: Thomas
Date:
Subject: Re: need some advanced books on Postgres
Next
From: Scott Marlowe
Date:
Subject: Re: kernel version impact on PostgreSQL performance