Re: Auditing extension for PostgreSQL (Take 2)

Поиск
Список
Период
Сортировка
От David Steele
Тема Re: Auditing extension for PostgreSQL (Take 2)
Дата
Msg-id 55429DA5.40503@pgmasters.net
обсуждение исходный текст
Ответ на Re: Auditing extension for PostgreSQL (Take 2)  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: Auditing extension for PostgreSQL (Take 2)  (Sawada Masahiko <sawada.mshk@gmail.com>)
Список pgsql-hackers
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.

--
- David Steele
david@pgmasters.net

Вложения

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

Предыдущее
От: Kouhei Kaigai
Дата:
Сообщение: Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: PATCH: adaptive ndistinct estimator v4