Re: [PATCH] Add pg_current_vxact_id() function to expose virtual transaction IDs - Mailing list pgsql-hackers

From Henson Choi
Subject Re: [PATCH] Add pg_current_vxact_id() function to expose virtual transaction IDs
Date
Msg-id 176692871775.510795.12048377873555663209.pgcf@coridan.postgresql.org
Whole thread Raw
In response to [PATCH] Add pg_current_vxact_id() function to expose virtual transaction IDs  ("Pavlo Golub" <pavlo.golub@cybertec.at>)
List 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.

pgsql-hackers by date:

Previous
From: Zsolt Parragi
Date:
Subject: Re: RFC: PostgreSQL Storage I/O Transformation Hooks
Next
From: Peter Eisentraut
Date:
Subject: Re: Change some Datum to void * for opaque pass-through pointer