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

From Fujii Masao
Subject Re: pgaudit - an auditing extension for PostgreSQL
Date
Msg-id CAHGQGwEbuOihJ3C9rOEFLVsVjgiwSvHM9-ytC6zx4+bjBaP7qA@mail.gmail.com
Whole thread Raw
In response to Re: pgaudit - an auditing extension for PostgreSQL  (David Steele <david@pgmasters.net>)
Responses Re: pgaudit - an auditing extension for PostgreSQL
List 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 by date:

Previous
From: Thom Brown
Date:
Subject: Re: GSoC 2015 - mentors, students and admins.
Next
From: Amit Kapila
Date:
Subject: Re: Parallel Seq Scan