Subject: Re: Best Tool for PostgreSQL Auditing and Storing Audit Logs Separately

From: Achilleas Mantzios - cloud <[email-masked]>
Date: Wed, 16 Apr 2025 10:10:22 +0100

On 4/15/25 12:14, KENAN ÇİFTÇİ wrote:

> Hi,
>
> You can use pgaudit and pgauditlogtofile extension 
> (https://github.com/fmbiete/pgauditlogtofile) together to write audit 
> logs in a separate file.
One issue we have with pgaudit is that it prints AUDIT records even if 
the xaction gets rollbacked, how do you alleviate that ?
>
> yours,
>
> Kenan Çiftçi
>
> On Tue, Apr 15, 2025 at 1:44 PM vijay patil <[email-masked]> 
> wrote:
>
>     Hi All,
>
>     We are exploring auditing solutions for our PostgreSQL database
>     and are considering using |pgaudit| for this purpose. However, we
>     have a few questions:
>
>     1.
>
>         *What is the best tool for auditing PostgreSQL databases?*
>
>          *
>
>             We are specifically looking for a solution that offers
>             detailed auditing capabilities and is compatible with our
>             setup.
>
>     2.
>
>         *Can we store the audit information separately from PostgreSQL
>         logs if we decide to use |pgaudit|?*
>
>          *
>
>             We would prefer to keep the audit logs in a separate file
>             or location for easier management and analysis.
>
>
>     We appreciate any help or suggestions!
>
>
>     Thanks
>
>     Vijay
>

---

From: Ron Johnson <[email-masked]>
Date: Wed, 16 Apr 2025 08:36:06 -0400

pgaudit is statement-level, not transaction-level; that's its nature.  This
is the same as log_statement.

On Wed, Apr 16, 2025 at 5:10 AM Achilleas Mantzios - cloud <
[email-masked]> wrote:

> You can use pgaudit and pgauditlogtofile extension (
> https://github.com/fmbiete/pgauditlogtofile) together to write audit logs
> in a separate file.
>
> One issue we have with pgaudit is that it prints AUDIT records even if the
> xaction gets rollbacked, how do you alleviate that ?
>
>
> yours,
>
> Kenan Çiftçi
>
>> We are exploring auditing solutions for our PostgreSQL database and are
>> considering using pgaudit for this purpose. However, we have a few
>> questions:
>>
>>    1.
>>
>>    -
>>       We are specifically looking for a solution that offers detailed
>>       auditing capabilities and is compatible with our setup.
>>       2.
>>
>>    *Can we store the audit information separately from PostgreSQL logs
>>    if we decide to use pgaudit?*
>>    -
>>
>>       We would prefer to keep the audit logs in a separate file or
>>       location for easier management and analysis.
>>
>>

-- 
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

---

From: Achilleas Mantzios <[email-masked]>
Date: Wed, 16 Apr 2025 20:35:26 +0300

On 16/4/25 15:36, Ron Johnson wrote:

>
> pgaudit is statement-level, not transaction-level; that's its nature.  
> This is the same as log_statement.
ok, but log_statement prints ROLLBACKs/COMMITs, but pgaudit not.
>
> On Wed, Apr 16, 2025 at 5:10 AM Achilleas Mantzios - cloud 
> <[email-masked]> wrote:
>
>>     (https://github.com/fmbiete/pgauditlogtofile) together to write
>>     audit logs in a separate file.
>     One issue we have with pgaudit is that it prints AUDIT records
>     even if the xaction gets rollbacked, how do you alleviate that ?
>>
>>     yours,
>>
>>     Kenan Çiftçi
>>
>>     On Tue, Apr 15, 2025 at 1:44 PM vijay patil
>>     <[email-masked]> wrote:
>>
>>         Hi All,
>>
>>         We are exploring auditing solutions for our PostgreSQL
>>         database and are considering using |pgaudit| for this
>>         purpose. However, we have a few questions:
>>
>>         1.
>>
>>                 We are specifically looking for a solution that
>>                 offers detailed auditing capabilities and is
>>                 compatible with our setup.
>>
>>         2.
>>
>>             *Can we store the audit information separately from
>>             PostgreSQL logs if we decide to use |pgaudit|?*
>>
>>              *
>>
>>                 We would prefer to keep the audit logs in a separate
>>                 file or location for easier management and analysis.
>>
>>