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. 2025년 12월 8일 (월) PM 9:10, Pavlo Golub <[email protected]>님이 작성: > 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 >
