| 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.
| 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 |