public inbox for [email protected]  

help / color / mirror / Atom feed

From: Henson Choi <[email protected]>
To: Pavlo Golub <[email protected]>
Cc: [email protected]
Subject: Re: Re[2]: [PATCH] Add pg_current_vxact_id() function to expose virtual transaction IDs
Date: Fri, 9 Jan 2026 09:03:55 +0900
Message-ID: <CAAAe_zAJHcWVUD6RDpBWvo=dMwExqC2gXKsABNhRhwBE-s7DBw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<CAAAe_zAjUwkKJzj8AGwzDx9CPxdwyyVYcMYZi-5jQX7HMWkkXw@mail.gmail.com>
	<[email protected]>

Hi Pavlo,

2026년 1월 6일 (화) PM 10:32, Pavlo Golub <[email protected]>님이 작성:

> 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 = pg_backend_pid() LIMIT 1;
> While it is true that pg_locks contains the virtual transaction
> information, I believe there are strong technical reasons to expose this
> directly via a function.
>

Agreed.


> First of all, querying pg_locks is expensive. By contrast,
> pg_current_vxact_id() is a practically free O(1) read from MyProc.
>

Yes, this is a significant advantage. The function simply reads from
MyProc without any locking or iteration.


> The %v log placeholder is the specific identifier for individual
> transaction executions (including read-only ones where no permanent XID
> is assigned). PIDs (%p) are session-scoped and too coarse for helping
> debug specific transactions in connection-pooled environments. This
> function allows applications to easily obtain the ID needed to correlate
> with server logs.
>

This is a compelling use case. In connection-pooled environments,
correlating application-side logs with server logs by VXID is much
more precise than using PIDs.


> We already provide fast accessors for other identifiers like
> pg_backend_pid() and pg_current_xact_id(). Additionally, PostgreSQL
> often provides utility functions that overlap with other commands or
> views to improve developer experience (e.g., pg_notify() vs NOTIFY,
> pg_sleep() vs pg_sleep_for() vs pg_sleep_until()). It feels consistent
> to offer a simple accessor rather than requiring a complex query against
> a system view.
>
>
I agree. This follows established PostgreSQL patterns.


> Best regards,
> Pavlo Golub
>
>
Additionally, the implementation is minimal (~20 lines), so the binary
size impact is negligible. And since it's a leaf function called only
when explicitly invoked by users, it has no impact on the main code
path performance.

Best regards,
Henson

view thread (3+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Re[2]: [PATCH] Add pg_current_vxact_id() function to expose virtual transaction IDs
  In-Reply-To: <CAAAe_zAJHcWVUD6RDpBWvo=dMwExqC2gXKsABNhRhwBE-s7DBw@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox