Re: pgaudit - an auditing extension for PostgreSQL

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: pgaudit - an auditing extension for PostgreSQL
Дата
Msg-id CAB7nPqQxFBqjwjrm8VW7JoRP6491Mc+MX65SjQbf8f-MBk-nGA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pgaudit - an auditing extension for PostgreSQL  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: pgaudit - an auditing extension for PostgreSQL  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: moving from contrib to bin
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: moving from contrib to bin