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
