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

From: Henson Choi <assam258(at)gmail(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: Pavlo Golub <pavlo(dot)golub(at)gmail(dot)com>
Subject: Re: [PATCH] Add pg_current_vxact_id() function to expose virtual transaction IDs
Date: 2025-12-28 13:31:57
Message-ID: 176692871775.510795.12048377873555663209.pgcf@coridan.postgresql.org
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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2025-12-28 13:40:03 Re: Change some Datum to void * for opaque pass-through pointer
Previous Message Zsolt Parragi 2025-12-28 13:12:09 Re: RFC: PostgreSQL Storage I/O Transformation Hooks