Re: pgaudit - an auditing extension for PostgreSQL - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: pgaudit - an auditing extension for PostgreSQL
Date
Msg-id 20140623174241.GO16098@tamriel.snowman.net
Whole thread Raw
In response to Re: pgaudit - an auditing extension for PostgreSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.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

pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: [HACKERS] please review source(SQLServer compatible)‏
Next
From: Pavel Stehule
Date:
Subject: Re: [Fwd: Re: proposal: new long psql parameter --on-error-stop]