I looked into where VXID is actually used:
SELECT c.relname, a.attname
FROM pg_attribute a JOIN pg_class c ON a.attrelid = c.oid
WHERE a.attname LIKE '%virtual%' AND a.attnum > 0;
relname | attname
----------+--------------------
pg_locks | virtualxid
pg_locks | virtualtransaction
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;
This always works since every transaction holds its own VXID lock.
For log correlation, PID works in most cases.
So I'm having trouble seeing a compelling use case. Could you share
a concrete scenario where this function would help?
The patch itself is clean, but I'm not sure about the justification.
Hi hackers,
I'd like to propose a new function pg_current_vxact_id() that returns
the
current backend's virtual transaction ID (VXID).
Virtual transaction IDs are fundamental to PostgreSQL's transaction
tracking,
appearing in pg_locks.virtualtransaction, log output via %v placeholder,
and
internal transaction management. However, there's currently no direct
SQL
function to retrieve the current VXID, forcing applications to query
pg_locks
or parse log files to obtain this information.
The patch adds pg_current_vxact_id() which returns the VXID as text in
the
format "procNumber/lxid" (e.g., "3/42"), matching the format used
throughout
PostgreSQL for consistency.
Use cases:
1. Application transaction tracking and correlation with logs
2. Monitoring read-only transactions (which never get regular XIDs)
3. Debugging transaction behavior without querying pg_locks
4. Building monitoring tools that need consistent transaction identity
The function follows the same pattern as pg_current_xact_id() and
pg_current_xact_id_if_assigned(), providing a clean API for a commonly
needed piece of information.
Changes:
- Added function in xid8funcs.c (alongside related transaction ID
functions)
- OID 5101 (verified available with unused_oids script)
- Comprehensive regression tests in xid.sql
- Documentation in func-info.sgml and xact.sgml
- Format kept in sync with existing VXID representations in elog.c and
lockfuncs.c
The v1 patch is attached. Tests pass cleanly with "meson test
regress/regress".
Best regards,
Pavlo Golub
