Re: PostgreSQL Audit Extension

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, David Steele <david(at)pgmasters(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Subject: Re: PostgreSQL Audit Extension
Date: 2016-02-18 03:25:26
Message-ID: 20160218032526.GE26716@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 17, 2016 at 01:59:09PM +0530, Robert Haas wrote:
> On Wed, Feb 17, 2016 at 5:20 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > On Fri, Feb 5, 2016 at 01:16:25PM -0500, Stephen Frost wrote:
> >> Looking at pgaudit and the other approaches to auditing which have been
> >> developed (eg: applications which sit in front of PG and essentially
> >> have to reimplement large bits of PG to then audit the commands sent
> >> before passing them to PG, or hacks which try to make sense out of log
> >> files full of SQL statements) make it quite clear, in my view, that
> >> attempts to bolt-on auditing to PG result in a poorer solution, from a
> >> technical perspective, than what this project is known for and capable
> >> of. To make true progress towards that, however, we need to get past
> >> the thinking that auditing doesn't need to be in-core or that it should
> >> be a second-class citizen feature or that we don't need it in PG.
> >
> > Coming in late here, but the discussion around how to maintain the
> > auditing code seems very similar to how to handle the logical
> > replication of DDL commands. First, have we looked into hooking
> > auditing into scanning logical replication contents, and second, how are
> > we handling the logical replication of DDL and could we use the same
> > approach for auditing?
>
> Auditing needs to trace read-only events, which aren't reflected in
> logical replication in any way. I think it's a good idea to try to
> drive auditing off of existing machinery instead of inventing
> something new - I suggested plan invalidation items upthread. But I
> doubt that logical replication is the thing to attach it to.

I was suggesting we could track write events via logical replication and
then we only have to figure out auditing of read events, which would be
easier.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-02-18 03:52:45 Re: Fix handling of invalid sockets returned by PQsocket()
Previous Message Peter Eisentraut 2016-02-18 02:47:50 pg_ctl promote wait