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.
First of all, querying pg_locks is expensive. By contrast,
pg_current_vxact_id() is a practically free O(1) read from MyProc.
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.
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.
Best regards,
Pavlo Golub
