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