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

From Abhijit Menon-Sen
Subject Re: pgaudit - an auditing extension for PostgreSQL
Date
Msg-id 20140623105153.GJ31357@toroid.org
Whole thread Raw
In response to Re: pgaudit - an auditing extension for PostgreSQL  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: pgaudit - an auditing extension for PostgreSQL
Re: pgaudit - an auditing extension for PostgreSQL
List pgsql-hackers
(I'm replying as co-author of pgaudit.)

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.

> > Planned future improvements include:
> >
> > 1. Additional logging facilities, including to a separate audit
> >    log file and to syslog, and potentially logging to a table
> >    (possibly via a bgworker process). Currently output is simply
> >    emitted to the server log via ereport().
> >
> > 2. To implement per-object auditing configuration, it would be nice
> >    to use extensible reloptions (or an equivalent mechanism)
>
> Is it possible to implement these outside PostgreSQL by using hooks?

There are some unresolved questions with #2 because the extensible
reloptions patch seems to have lost favour, but I'm pretty sure we
could figure out some alternative.

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

-- Abhijit

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: idle_in_transaction_timeout
Next
From: David Rowley
Date:
Subject: Re: Allowing join removals for more join types