Re: Auditing extension for PostgreSQL (Take 2) - Mailing list pgsql-hackers

On Fri, May 1, 2015 at 6:24 AM, David Steele <david@pgmasters.net> wrote:
> On 4/30/15 6:05 AM, Fujii Masao wrote:
>> On Thu, Apr 30, 2015 at 12:57 PM, Sawada Masahiko <sawada.mshk@gmail.com> wrote:
>>>
>>> I have changed the status this to "Ready for Committer".
>>
>> The specification of "session audit logging" seems to be still unclear to me.
>> For example, why doesn't "session audit logging" log queries accessing to
>
> The idea was that queries consisting of *only* catalog relations are
> essentially noise.  This makes the log much quieter when tools like psql
> or PgAdmin are in use.  Queries that contain a mix of catalog and user
> tables are logged.
>
> However, you make a good point, so in the spirit of cautious defaults
> I've changed the behavior to log in this case and allow admins to turn
> off the behavior if they choose with a new GUC, pg_audit.log_catalog.
>
>> a catalog like pg_class? Why doesn't it log any queries executed in aborted
>> transaction state? Since there is no such information in the document,
>
> The error that aborts a transaction can easily be logged via the
> standard logging facility.  All prior statements in the transaction will
> be logged with pg_audit.  This is acceptable from an audit logging
> perspective as long as it is documented behavior, which as you point out
> it currently is not.
>
> This has now been documented in the caveats sections which should make
> it clearer to users.
>
>> I'm afraid that users would easily get confused with it. Even if we document it,
>> I'm not sure if the current behavior is good for the audit purpose. For example,
>> some users may want to log even queries accessing to the catalogs.
>
> Agreed, and this is now the default.
>
>> I have no idea about when the current CommitFest will end. But probably
>> we don't have that much time left. So I'm thinking that maybe we should pick up
>> small, self-contained and useful part from the patch and focus on that.
>> If we try to commit every features that the patch provides, we might get
>> nothing at least in 9.5, I'm afraid.
>
> May 15th is the feature freeze, so that does give a little time.  It's
> not clear to me what a "self-contained" part of the patch would be.  If
> you have specific ideas on what could be broken out I'm interested to
> hear them.
>
> Patch v11 is attached with the changes discussed here plus some other
> improvements to the documentation suggested by Erik.
>

For now, since pg_audit patch has a pg_audit_ddl_command_end()
function which uses part of un-committed "deparsing utility commands"
patch API,
pg_audit patch is completely depend on that patch.
If API name, interface are changed, it would affect for pg_audit patch.
I'm not sure about progress of "deparsing utility command" patch but
you have any idea if that patch is not committed into 9.5 until May
15?

Regards,

-------
Sawada Masahiko