Thread

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

    Henson Choi <assam258@gmail.com> — 2025-12-28T15:52:18Z

    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 <pavlo.golub@cybertec.at>님이 작성:
    
    > 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
    >