From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, MauMau <maumau307(at)gmail(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, 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-16 18:28:07 |
Message-ID: | 20141216182806.GY25679@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Michael Paquier (michael(dot)paquier(at)gmail(dot)com) wrote:
> 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.
While these performance numbers would be interesting, I don't feel it's
necessary to consider the performance of this module as part of the
question about if it should go into contrib or not.
> 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.
What I was hoping to see were the changes that I had suggested
up-thread, but I discovered about a week or two ago that there was a
misunderstanding between at least Abhijit and myself about what was
being suggested.
For the sake of the archives, the idea I had been trying to propose is
to use a role's permissions as a mechanism to define what should be
audited. An example is:
The magic "audit" role has SELECT rights on a given table. When any
user does a SELECT against that table, ExecCheckRTPerms is called and
there's a hook there which the module can use to say "ok, does the audit
role have any permissions here?" and, if the result is yes, then the
command is audited. Note that this role, from core PG's perspective,
wouldn't be special at all; it would just be that pgaudit would use the
role's permissions as a way to figure out if a given command should be
audited or not.
That's not to say that we couldn't commit pgaudit without this
capability and add it later, but I had been expecting to see progress
along these lines prior to reviewing it.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2014-12-16 18:33:32 | Re: Commitfest problems |
Previous Message | Stephen Frost | 2014-12-16 18:21:49 | Re: Commitfest problems |