Thread

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

solai v <solai.cdac@gmail.com> — 2026-05-14T11:26:27Z

Hi all,

I went through the discussion and tested the patch on my current
branch and I wanted to share a few observations based on my findings.
One of the concerns raised was whether this is primarily a convenience
wrapper around existing functionality via pg_locks. While it is
technically possible to retrieve the VXID from
pg_locks.virtualtransaction, the behavior in practice is not
equivalent. pg_locks exposes lock-level entries (a single transaction
can appear multiple times), requiring additional filtering or
deduplication. In that sense, it is not a direct representation of
transaction identity. While it is technically possible to obtain the
VXID via pg_locks, that approach is indirect and tied to lock-level
representation. Providing a dedicated function exposes an already
existing transaction identifier in a way that is consistent, reliable,
and appropriate for its semantics. From the testing, what stood out
clearly is that VXID is the only identifier that is consistently
available across all transaction states. In read-only transactions and
before any write, pg_current_xact_id_if_assigned() returns NULL, while
VXID is already present and stable. Even after XID assignment, VXID
remains unchanged throughout the transaction lifetime. This makes VXID
fundamentally different from XID in terms of observability and also
the only identifier that exists uniformly for all transactions.
Providing a direct SQL interface, compared to accessing it via
pg_locks or log_line_prefix (%v), seems consistent with existing
exposure patterns. So from a usability and observability point of
view, this will be like adding a convenience function and more like
filling a small but real gap in the SQL interface.
Overall, the patch behavior is consistent across transaction states
and the patch looks good to me.

Regards,
Solai