Re: pgaudit - an auditing extension for PostgreSQL

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: pgaudit - an auditing extension for PostgreSQL
Дата
Msg-id 20140623174241.GO16098@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: pgaudit - an auditing extension for PostgreSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > I'd expect a catalog table or perhaps changes to pg_class (maybe other
> > things also..) to define what gets logged.
>
> How exactly will that work for log messages generated in contexts where
> we do not have working catalog access?  (postmaster, crash recovery,
> or pretty much anywhere where we're not in a valid transaction.)

Certainly a great question and we may have to address it by not
supporting changes immediately (in other words, cache things at backend
start, or only at specific times), or by reviewing what logging we do at
those times and work out which of those can be controllerd through the
catalog and which can't.  The logging which can't be managed through the
catalog would have to be managed through GUCs or in another way.

There's a difference between being able to have finer grained control
over certain log messages and having every single ereport() query the
catalog.  I'm not advocating the latter.

> This strikes me as much like the periodic suggestions we hear to get
> rid of the GUC infrastructure in favor of keeping all those settings
> in a table.  It doesn't work because too much of that info is needed
> below the level of working table access.

I'm not suggesting this.
Thanks,
    Stephen

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

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: [HACKERS] please review source(SQLServer compatible)‏
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: [Fwd: Re: proposal: new long psql parameter --on-error-stop]