Re: Auditing via logical decoding

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: Auditing via logical decoding
Дата
Msg-id 9bb4c1e1-a8db-cef0-8093-d4f4a3813014@2ndquadrant.com
обсуждение исходный текст
Ответ на RE: Auditing via logical decoding  (<from_postgres@safetyphil.com>)
Список pgsql-hackers

On 07/27/2018 04:43 PM, from_postgres@safetyphil.com wrote:
>>> We have been using our own trigger-based audit system at my firm 
>>> successfully for some years, but the performance penalty is
>>> starting to grate a bit and so I have been tasked with seeing if
>>> we can make use of the new logical decoding functions to achieve
>>> the same thing. I thought that someone must already have written
>>> something that would satisfy our use-case but my internet
>>> searches have come up short so far so I am considering writing a
>>> logical decoding plugin to do what we want.
> 
>> Have you checked pgaudit [1]? I haven't checked if it matches all
>> your requirements, but considering it's an extension aimed at
>> auditing use cases it might. And it's already available, of
>> course.
> 
> Actually no, I hadn't come across this before, thanks for the heads
> up. It is important for us to be able to get the audit data back into
> a different database, but it looks like I could scrape the logs and
> do that. At the very least it shows that it is possible to hook into
> postgres in the right places to emit extra logical messages if that
> turns out to be the better way to do it.
> 
> It doesn't appear to support application_name, nor the connection
> details of the user doing the update - but perhaps that would be just
> as sensible to add it here than in a logical output plugin.
> 
> It's a bit tricky coming to a big codebase like postgres and trying
> to decide the best route of doing something; I don't have much of a
> mental model about how complicated the various systems are :)
> 

It may not support everything, but in general when a feature can be done 
in an extension, it's generally faster to deliver that way. One of the 
reasons is the ad hoc release cycle (compared to the 1-per-year cycle of 
PostgreSQL). So I'd suggest investigating this option first.

It may not meet all your requirements immediately (or at all), but well, 
no solution probably will.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: Locking B-tree leafs immediately in exclusive mode
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Auditing via logical decoding