Hello! On Tue, Apr 14, 2026 at 3:58 PM Andres Freund <[email protected]> wrote: > I still think this needs to be in the deadlock detector. The lock cycle just > needs to be a bit more complicated for a hack in JoinWaitQueue not to work. > There's no guarantee that the wait that triggers the deadlock is actually on > the relation being repacked.
I have started prototyping a way to declare a "future" lock which the deadlock detector treats as a hard edge. But I currently stuck on issues related to the fact that SUE doesn't force weak locks (fast-path) to go through FastPathTransferRelationLocks, so the deadlock detector can't handle the case when another backend tries to execute LOCK TABLE repack_test IN SHARE UPDATE EXCLUSIVE MODE; Also, VACUUM takes the same lock. I'm not sure how to deal with this in a non-hacky way. One option is to force SUE to transfer locks if relation it is trying to lock relation which marked with "future lock". But I am not sure it is good enough or covers all tricky cases (multiple backends in the loop). Best regards, Mikhail.
