Re: [PATCH v4] Add pg_current_vxact_id() function

From: shihao zhong <zhong950419(at)gmail(dot)com>
To: Pavlo Golub <pavlo(dot)golub(at)cybertec(dot)at>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, assam258(at)gmail(dot)com, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH v4] Add pg_current_vxact_id() function
Date: 2026-08-29 05:25:16
Message-ID: CAGRkXqTfczyDEhxzGhHHz1axFPgPDYfTc2DJ_cKx01DHYAjzGA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 21, 2026 at 11:42 AM Pavlo Golub <pavlo(dot)golub(at)cybertec(dot)at> wrote:
>
> The function returns NULL during recovery or when no valid VXID exists.

On a standby the function actually returns the VXID just fine -- the
code only guards on MyProc/procNumber, which is the same condition %v
uses, and StartTransaction assigns the vxid unconditionally during
recovery (no RecoveryInProgress guard anywhere). We should change
the commit message.

Example:
SELECT pg_is_in_recovery();
pg_is_in_recovery
-------------------
t

SELECT pg_current_vxact_id();
pg_current_vxact_id
---------------------
2/3

On the use case: I first thought monitoring recovery conflicts might be a
good example, but we can already do that with the PID. The cancelled query
already logged PID plus timestamp.

The only thing a VXID gives you over a PID is telling
multiple transactions within the same backend/session, and I haven't
been able to come up with a concrete case where you'd actually need that.

Does anyone have one?

Thanks,
Shihao

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Laurenz Albe 2026-08-29 06:14:45 Re: Adding a stored generated column without long-lived locks
Previous Message Bharath Rupireddy 2026-08-29 05:09:00 Re: Online enable/disable data checksums functions return success even when the launcher fails to start