Re: New feature request for adding session information to PostgreSQL transaction log

From: Chapman Flack <jcflack(at)acm(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Sumanth Vishwaraj <sumanth(dot)vishwaraj(at)oracle(dot)com>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Mahesh Rao <mahesh(dot)p(dot)rao(at)oracle(dot)com>, Nazia Zaidi <najiah(dot)abide(at)oracle(dot)com>, Jitesh Tiwari <jitesh(dot)tiwari(at)oracle(dot)com>, Nick Wagner <nick(dot)wagner(at)oracle(dot)com>, Scott Corbin <scott(dot)corbin(at)oracle(dot)com>, Mack Bell <mack(dot)bell(at)oracle(dot)com>, Avinash Dubey <avinash(dot)x(dot)dubey(at)oracle(dot)com>
Subject: Re: New feature request for adding session information to PostgreSQL transaction log
Date: 2025-01-21 18:28:43
Message-ID: 678FE75B.2020101@acm.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 01/19/25 12:02, Tom Lane wrote:
> You can build that yourself, typically by adding a trigger that stores
> the value of "current_user" into inserted/updated rows. (If you want
> to also track deletions, a separate audit log table would work
> better.) The event-trigger feature might also be useful.

I wonder how close one could get to the customer request (better
forensics without having to build extra columns and triggers at the
SQL level) with an extension and existing hooks.

I haven't used it, but isn't there now a facility for inserting
additional custom records into the WAL? With ClientAuthentication_hook,
could an extension add a record there for the creation of a new session,
with timestamp and authenticated role oid?

Could an XactCallback be used to add a custom record at commit time
identifying the responsible session? There would then be enough breadcrumbs
to follow forensically from the commit to the session to the credentials.

An added custom record at commit time likely costs more in space than
extending the existing commit record with a session id, but seems like
something an extension could do without changes in core.

Forensic information would then be present with no need for a customer
to build extra table columns and triggers. It would be recorded
transparently, and would need some custom WAL-reading forensic tool
to piece it back together if ever needed. But just such a facility would
have made me quite happy back when I was experimenting[1] with using
pg_commit_ts forensically.

Regards,
-Chap

[1]
https://www.postgresql.org/message-id/8527e4bf-a3c0-f056-978b-ff4096951e3d%40anastigmatix.net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2025-01-21 18:36:11 Re: Skip collecting decoded changes of already-aborted transactions
Previous Message Tom Lane 2025-01-21 18:27:15 Re: Year of first commit