Re: Auditing extension for PostgreSQL (Take 2)

From: David Steele <david(at)pgmasters(dot)net>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, er(at)xs4all(dot)nl
Subject: Re: Auditing extension for PostgreSQL (Take 2)
Date: 2015-04-30 21:24:53
Message-ID: 55429DA5.40503@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
- David Steele
david(at)pgmasters(dot)net

Attachment Content-Type Size
pg_audit-v11.patch text/plain 110.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2015-04-30 21:31:48 Re: PATCH: adaptive ndistinct estimator v4
Previous Message Kouhei Kaigai 2015-04-30 21:21:06 Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)