So, I see three possible ways to fix this problem:
1. Yury Sololov's patch with two phase deadlock check
I could be wrong, but LWLocks in pgsql aren't a "fair" locks: if LWLock is share
locked then exclusive lock will wait, but next shared lock will be acquired
immediately. If so, the we have a risk when two deadlocked processes will
infinitely wait for excluse lock over partitions while other processes will
repeady lock for share to find its owned deadlocks. I.e. lock graph has one loop
and members of that loop could not acquire exclusive lock becouse non-members of
loop constantly holds a share lock. It has a low probability, but nevertheless.
2. Avoid concurrent deadlock detection
Seems simple, workable solution with unpredicable delay for deadlock check.
Although it helps very good in cases when there isn't deadlock.
3. Avoid concurrent deadlock detection + let CheckDeadLock detect all deadlocks,
not only those in which current transaction is involved.
I think, it's better solution, but I'm afraid it's too late for 11v...
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
