Hello! I think I got working POC for deadlock-detector enhancements for REPACK (and potentially other).
Each PGPROC gets one FutureWaitLock slot: a (locktag, mode) pair, which is empty when locktag_lockmethodid == 0. A backend calls LockDeclareFutureWait() to publish its intent. Only REPACK (CONCURRENTLY) uses it today, declaring its future AccessExclusiveLock. Only the owning backend writes its slot; it does so under the partition lock covering the declared tag. Remote readers (the deadlock detector) must hold that partition lock to observe it. The detector holds all partition locks during its graph walk, so it can read any slot safely. The slot clears in LockAcquireExtended() at the exact point the backend attaches its waitLink for the same tag and mode. It is also cleared on abort, backend exit, and end of transaction. FindLockCycleRecurseFuture() treats the declared future lock as a hard edge to (a) current holders whose mode conflicts and (b) already-queued waiters that JoinWaitQueue() would place ahead of the future request. Weak relation locks are kept in per-backend fast-path arrays and remain invisible to the detector's graph walk. Normally LockAcquireExtended() migrates them to the main lock table when a conflicting strong lock is requested. This action is gated by FastPathStrongRelationLocks->count to prevent new fast-path lock processing. A future-wait declaration does not trigger that migration due to performance considerations. Instead CheckDeadLock() now snapshots currently declared fast-path-incompatible future waits and increments FastPathStrongRelationLocks->count for those tags (blocking new fast-path acquisitions). It then calls FastPathTransferRelationLocks() for each such tag to move existing holders into the main table, making everything visible to the deadlock walker. Once the deadlock checker finishes, FastPathStrongRelationLocks->count is decremented enabling fast-path processing again. Performance degradation occurs only during deadlock processing and only if REPACK is active. If a deadlock contains a "future" edge it is reported as "future deadlock detected". Repack first declares future AE and only then proceeds to actually get SUE. Added test cases for different scenarios, including SUE from another backend and a 3-backend deadlock.
nocfbot-v2-0001-Detect-deadlocks-involving-declared-future-lock-r.patch
Description: Binary data
