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

From Fujii Masao
Subject Re: pgaudit - an auditing extension for PostgreSQL
Date
Msg-id CAHGQGwGMud+DPr3q8yrv5P+Uq49TPhJGCLdF+q9yNCrBgJfEFw@mail.gmail.com
Whole thread Raw
In response to Re: pgaudit - an auditing extension for PostgreSQL  (Stephen Frost <sfrost@snowman.net>)
Responses Re: pgaudit - an auditing extension for PostgreSQL  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Mon, Jun 23, 2014 at 9:50 PM, Stephen Frost <sfrost@snowman.net> wrote:
> * Fujii Masao (masao.fujii@gmail.com) wrote:
>> On Mon, Jun 23, 2014 at 7:51 PM, Abhijit Menon-Sen <ams@2ndquadrant.com> wrote:
>> > At 2014-06-23 19:15:39 +0900, masao.fujii@gmail.com wrote:
>> >> You added this into CF, but its patch has not been posted yet. Are you
>> >> planning to make a patch?
>> >
>> > It's a self-contained contrib module. I thought Ian had posted a
>> > tarball, but it looks like he forgot to attach it (or decided to
>> > provide only a Github link). I've attached a tarball here for
>> > your reference.
>
> I'm not a huge fan of adding this as a contrib module unless we can be
> quite sure that there's a path forward from here to a rework of the
> logging in core which would actually support the features pg_audit is
> adding, without a lot of pain and upgrade issues.  Those issues have
> kept other contrib modules from being added to core.
>
> Splitting up contrib into other pieces, one of which is a 'features'
> area, might address that but we'd really need a way to have those pieces
> be able to include/add catalog tables, at least..
>
>> >> If not, it might be better to implement audit feature in core from the
>> >> beginning.
>> >
>> > Sure, we're open to that possibility. Do you have any ideas about what
>> > an in-core implementation should do/look like?
>>
>> I don't have good idea about that. But maybe we can merge pgaudit.log
>> into log_statement for more flexible settings of what to log.
>
> I'd expect a catalog table or perhaps changes to pg_class (maybe other
> things also..) to define what gets logged..

I'm not sure if this is good idea because this basically means that master
and every standbys must have the same audit settings and a user cannot
set what standby logs in standby side. Of course I guess that the audit
settings in standby would be similar to that in master generally, but I'm
not sure if that's always true.

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: idle_in_transaction_timeout
Next
From: Noah Misch
Date:
Subject: Re: PostgreSQL in Windows console and Ctrl-C