From: "Pavlo Golub" <pavlo.golub@cybertec.at>
To: assam258@gmail.com
Subject: Re[2]: [PATCH] Add pg_current_vxact_id() function to expose virtual
 transaction IDs
Cc: pgsql-hackers@lists.postgresql.org
Date: Tue, 06 Jan 2026 13:32:16 +0000
Message-Id: <em14322cd4-f84a-485d-b8d8-7dc2e2c58035@cybertec.at>
In-Reply-To: <CAAAe_zAjUwkKJzj8AGwzDx9CPxdwyyVYcMYZi-5jQX7HMWkkXw@mail.gmail.com>
References: <em5af9cba4-8cd3-4c9a-a593-c985d1c373ee@18a0083a.com>
 <CAAAe_zAjUwkKJzj8AGwzDx9CPxdwyyVYcMYZi-5jQX7HMWkkXw@mail.gmail.com>
Reply-To: "Pavlo Golub" <pavlo.golub@cybertec.at>
User-Agent: eM_Client/10.4.4195.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/em14322cd4-f84a-485d-b8d8-7dc2e2c58035%40cybertec.at>
Precedence: bulk

Hello.

Thanks for the review.

>
>Only pg_locks has it. And you can already get your VXID from there:
>
>   SELECT virtualtransaction FROM pg_locks
>   WHERE pid =3D pg_backend_pid() LIMIT 1;
While it is true that pg_locks contains the virtual transaction=20
information, I believe there are strong technical reasons to expose this=20
directly via a function.
First of all, querying pg_locks is expensive. By contrast,=20
pg_current_vxact_id() is a practically free O(1) read from MyProc.
The %v log placeholder is the specific identifier for individual=20
transaction executions (including read-only ones where no permanent XID=20
is assigned). PIDs (%p) are session-scoped and too coarse for helping=20
debug specific transactions in connection-pooled environments. This=20
function allows applications to easily obtain the ID needed to correlate=20
with server logs.
We already provide fast accessors for other identifiers like=20
pg_backend_pid() and pg_current_xact_id(). Additionally, PostgreSQL=20
often provides utility functions that overlap with other commands or=20
views to improve developer experience (e.g., pg_notify() vs NOTIFY,=20
pg_sleep() vs pg_sleep_for() vs pg_sleep_until()). It feels consistent=20
to offer a simple accessor rather than requiring a complex query against=20
a system view.

Best regards,
Pavlo Golub