On Wednesday, August 5th, 2026 at 6:23 AM, Shinya Kato <[email protected]> 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
signature.asc
Description: OpenPGP digital signature
