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

From Michael Paquier
Subject Re: pgaudit - an auditing extension for PostgreSQL
Date
Msg-id CAB7nPqQxFBqjwjrm8VW7JoRP6491Mc+MX65SjQbf8f-MBk-nGA@mail.gmail.com
Whole thread Raw
In response to Re: pgaudit - an auditing extension for PostgreSQL  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: pgaudit - an auditing extension for PostgreSQL
List pgsql-hackers
On Fri, Oct 17, 2014 at 7:44 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> Thanks for the review.
>
> On 16 October 2014 23:23, MauMau <maumau307@gmail.com> wrote:
>
>> (3)
>> SELECT against a view generated two audit log lines, one for the view
>> itself, and the other for the underlying table.  Is this intended?  I'm not
>> saying that's wrong but just asking.
>
> Intended
>
>> (4)
>> I'm afraid audit-logging DML statements on temporary tables will annoy
>> users, because temporary tables are not interesting.
>
> Agreed.
>
>> (5)
>> This is related to (4).  As somebody mentioned, I think the ability to
>> select target objects of audit logging is definitely necessary.  Without
>> that, huge amount of audit logs would be generated for uninteresting
>> objects.  That would also impact performance.
>
> Discussed and agreed already
>
>> (6)
>> What's the performance impact of audit logging?  I bet many users will ask
>> "about what percentage would the throughtput decrease by?"  I'd like to know
>> the concrete example, say, pgbench and DBT-2.
>
> Don't know, but its not hugely relevant. If you need it, you need it.

Do you have real numbers about the performance impact that this module
has when plugged in the server? If yes, it would be good to get an
idea of how much audit costs and if it has a clear performance impact
this should be documented to warn the user. Some users may really need
audit features as you mention, but the performance drop could be an
obstacle for others so they may prefer continue betting on performance
instead of pgaudit.

>> (8)
>> The code looks good.  However, I'm worried about the maintenance.  How can
>> developers notice that pgaudit.c needs modification when they add a new SQL
>> statement?  What keyword can they use to grep the source code to find
>> pgaudit.c?
>
> Suggestions welcome.
Where are we on this? This patch has no activity for the last two
months... So marking it as returned with feedback. It would be good to
see actual numbers about the performance impact this involves.
Regards,
-- 
Michael



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: moving from contrib to bin
Next
From: Michael Paquier
Date:
Subject: Re: moving from contrib to bin