Re: pgaudit - an auditing extension for PostgreSQL

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: MauMau <maumau307(at)gmail(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Ian Barwick <ian(at)2ndquadrant(dot)com>
Subject: Re: pgaudit - an auditing extension for PostgreSQL
Date: 2014-12-15 02:49:48
Message-ID: CAB7nPqQxFBqjwjrm8VW7JoRP6491Mc+MX65SjQbf8f-MBk-nGA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 17, 2014 at 7:44 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> Thanks for the review.
>
> On 16 October 2014 23:23, MauMau <maumau307(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2014-12-15 02:53:08 Re: moving from contrib to bin
Previous Message Peter Eisentraut 2014-12-15 02:45:45 Re: moving from contrib to bin