On Wed, Feb 17, 2016 at 5:20 AM, Bruce Momjian <br...@momjian.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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to