Re: Auditing extension for PostgreSQL (Take 2)

On Fri, May 1, 2015 at 6:24 AM, David Steele <david(at)pgmasters(dot)net> wrote:
> On 4/30/15 6:05 AM, Fujii Masao wrote:
>> On Thu, Apr 30, 2015 at 12:57 PM, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)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