Re: Re[2]: [PATCH] Add pg_current_vxact_id() function to expose virtual transaction IDs

Hi Pavlo,

2026년 1월 6일 (화) PM 10:32, Pavlo Golub <pavlo(dot)golub(at)cybertec(dot)at>님이 작성:

> Hello.
>
> Thanks for the review.
>
> >
> >Only pg_locks has it. And you can already get your VXID from there:
> >
> > SELECT virtualtransaction FROM pg_locks
> > WHERE pid = pg_backend_pid() LIMIT 1;
> While it is true that pg_locks contains the virtual transaction
> information, I believe there are strong technical reasons to expose this
> directly via a function.
>

Agreed.

> First of all, querying pg_locks is expensive. By contrast,
> pg_current_vxact_id() is a practically free O(1) read from MyProc.
>

Yes, this is a significant advantage. The function simply reads from
MyProc without any locking or iteration.

> The %v log placeholder is the specific identifier for individual
> transaction executions (including read-only ones where no permanent XID
> is assigned). PIDs (%p) are session-scoped and too coarse for helping
> debug specific transactions in connection-pooled environments. This
> function allows applications to easily obtain the ID needed to correlate
> with server logs.
>

This is a compelling use case. In connection-pooled environments,
correlating application-side logs with server logs by VXID is much
more precise than using PIDs.

> We already provide fast accessors for other identifiers like
> pg_backend_pid() and pg_current_xact_id(). Additionally, PostgreSQL
> often provides utility functions that overlap with other commands or
> views to improve developer experience (e.g., pg_notify() vs NOTIFY,
> pg_sleep() vs pg_sleep_for() vs pg_sleep_until()). It feels consistent
> to offer a simple accessor rather than requiring a complex query against
> a system view.
>
>
I agree. This follows established PostgreSQL patterns.

> Best regards,
> Pavlo Golub
>
>
Additionally, the implementation is minimal (~20 lines), so the binary
size impact is negligible. And since it's a leaf function called only
when explicitly invoked by users, it has no impact on the main code
path performance.

Best regards,
Henson