Re: pgaudit - an auditing extension for PostgreSQL

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: pgaudit - an auditing extension for PostgreSQL
Дата
Msg-id CAHGQGwEbuOihJ3C9rOEFLVsVjgiwSvHM9-ytC6zx4+bjBaP7qA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pgaudit - an auditing extension for PostgreSQL  (David Steele <david@pgmasters.net>)
Ответы Re: pgaudit - an auditing extension for PostgreSQL  (David Steele <david@pgmasters.net>)
Список pgsql-hackers
On Wed, Feb 18, 2015 at 1:26 AM, David Steele <david@pgmasters.net> wrote:
> On 2/17/15 10:23 AM, Simon Riggs wrote:
>> I vote to include pgaudit in 9.5, albeit with any changes. In
>> particular, David may have some changes to recommend, but I haven't
>> seen a spec or a patch, just a new version of code (which isn't how we
>> do things...).
>
> I submitted the new patch in my name under a separate thread "Auditing
> extension for PostgreSQL (Take 2)" (54E005CC.1060605@pgmasters.net)

I played the patch version of pg_audit a bit and have basic comments about
its spec.

The pg_audit doesn't log BIND parameter values when prepared statement is used.
Seems this is an oversight of the patch. Or is this intentional?

The pg_audit cannot log the statement like "SELECT 1" which doesn't access to
the database object. Is this intentional? I think that there are many users who
want to audit even such statement.

Imagine the case where you call the user-defined function which executes
many nested statements. In this case, pg_audit logs only top-level statement
(i.e., issued directly by client) every time nested statement is executed.
In fact, one call of such UDF can cause lots of *same* log messages. I think
this is problematic.

Regards,

-- 
Fujii Masao



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thom Brown
Дата:
Сообщение: Re: GSoC 2015 - mentors, students and admins.
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Parallel Seq Scan