Re: Report oldest xmin source when autovacuum cannot remove tuples

On Wednesday, August 5th, 2026 at 6:23 AM, Shinya Kato <shinya11(dot)kato(at)gmail(dot)com> wrote:

> > We already seem to have agreement on capturing the blocker during
> > ComputeXidHorizons() [1] [2].
>

> I do not read those messages that way. The first is a question from
> Scott, which I answered the next day.

This is the correct reading of my message.

> But ties among snapshot
> holders still resolve by scan order. With one active and one
> idle-in-transaction session pinning the same xmin, the reported pid
> flipped depending on which connected first.

...

> Is this the right set of outputs for this series?

Consider these examples of diagnostic logging: log_lock_waits lists
every holder and the entire wait queue; log_recovery_conflict_waits
lists every conflicting pid; and deadlock reporting includes the
whole cycle. None tries to reduce a list to a single element.

We could print a summary like this:

oldest xmin blocker: idle in transaction (pid = 12345, xid = 661027)
replication slot "standby_a" also holds this xmin
12 other processes hold snapshots at this xmin

This message doesn't require complicated ranking or tie breaks, and
it's compact.

Also:

- If a slot is dropped after the scan but before the name lookup,
vacuum prints "(slot name = )", and if another slot is created at
the freed index, vacuum prints the name of the new, unrelated slot.
ReplicationSlotName()'s header comment warns about this TOCTOU.
Reading the name while holding the control lock would close the
window.

- The TAP test covers an idle xid owner but not an active xid owner:
every active transaction in the test only holds a snapshot.

--
Scott Ray