| From: | Henson Choi <assam258(at)gmail(dot)com> |
|---|---|
| To: | Pavlo Golub <pavlo(dot)golub(at)cybertec(dot)at> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH] Add pg_current_vxact_id() function to expose virtual transaction IDs |
| Date: | 2025-12-28 15:52:18 |
| Message-ID: | CAAAe_zAjUwkKJzj8AGwzDx9CPxdwyyVYcMYZi-5jQX7HMWkkXw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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(dot)golub(at)cybertec(dot)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
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joel Jacobson | 2025-12-28 16:10:24 | Re: Optimize LISTEN/NOTIFY |
| Previous Message | Henson Choi | 2025-12-28 15:51:15 | Re: RFC: PostgreSQL Storage I/O Transformation Hooks |