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
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 |