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
