> > > 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. > > You are absolutely right, thank you for catching that. The guard is:
if (MyProc == NULL || MyProc->vxid.procNumber == INVALID_PROC_NUMBER) That condition has nothing to do with recovery. It only covers very early backend startup before MyProc is initialized. The function works correctly on standbys, exactly as %v does in log output. The C comment and commit message have been corrected in v5. Patch v5 attached (only change from v4: corrected the recovery claim in the commit message and C comment). > 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? > > The other cases I have in mind involve correlating log entries that use %v in log_line_prefix. With %p you can identify the backend and with with %v you can additionally identify *which transaction within that backend* produced a log line. I see this as useful when a long-lived session issues many transactions and you want to match a specific ERROR or lock-wait line to the exact transaction in yourapplication log, not just to the session. I believe monitoring connection poolers could be improved with this function. When connection poolers run in session mode a pooler backend is reused across multiple client-level "sessions". The PID is the same for all of them, but the localXID monotonically increases, so pg_current_vxact_id() lets the application record a correlation token that uniquely identifies each pooled client transaction in the server log. And, of course, monitoring tools that join against pg_locks to detect blocking already work with VXIDs. pg_current_vxact_id() lets an application embed its own VXID in application-level logging without a round-trip through pg_locks. Regards, Pavlo Golub CYBERTEC PostgreSQL International GmbH
