Re: log_statement and syslog severity

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: G Dutton <gdutton+pgsql(at)inf(dot)ed(dot)ac(dot)uk>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: log_statement and syslog severity
Date: 2010-03-07 02:49:37
Message-ID: 201003070249.o272nbI18990@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Allan Kamau 2010-03-07 08:45:25 Avoiding duplicates (or at least marking them as such) in a "cumulative" transaction table.
Previous Message Bruce Momjian 2010-03-07 02:47:36 Re: XML performance tuning