Re: pgaudit - an auditing extension for PostgreSQL

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, Ian Barwick <ian(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgaudit - an auditing extension for PostgreSQL
Date: 2014-06-23 17:42:41
Message-ID: 20140623174241.GO16098@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom,

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > I'd expect a catalog table or perhaps changes to pg_class (maybe other
> > things also..) to define what gets logged.
>
> How exactly will that work for log messages generated in contexts where
> we do not have working catalog access? (postmaster, crash recovery,
> or pretty much anywhere where we're not in a valid transaction.)

Certainly a great question and we may have to address it by not
supporting changes immediately (in other words, cache things at backend
start, or only at specific times), or by reviewing what logging we do at
those times and work out which of those can be controllerd through the
catalog and which can't. The logging which can't be managed through the
catalog would have to be managed through GUCs or in another way.

There's a difference between being able to have finer grained control
over certain log messages and having every single ereport() query the
catalog. I'm not advocating the latter.

> This strikes me as much like the periodic suggestions we hear to get
> rid of the GUC infrastructure in favor of keeping all those settings
> in a table. It doesn't work because too much of that info is needed
> below the level of working table access.

I'm not suggesting this.

Thanks,

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2014-06-23 17:43:15 Re: [Fwd: Re: proposal: new long psql parameter --on-error-stop]
Previous Message Kevin Grittner 2014-06-23 17:22:55 Re: [HACKERS] please review source(SQLServer compatible)‏