On Tue, Mar 29, 2011 at 2:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> IIRC, the
> current deadlock detector always kills the process that detected the
> deadlock, but I *think* that's just a random choice and not an essential
> feature. If so, it'd be pretty easy to instead kill the lowest-priority
> xact among those involved in the deadlock.
I think it was just easier. To kill yourself you just exit with an
error. To kill someone else you have to deliver a signal and hope the
other process exits cleanly.
There are a bunch of things to wonder about too. If you don't kill
yourself then you might still be in a deadlock cycle so presumably you
have to reset the deadlock timer? What if two backends both decide to
kill the same other backend. Does it handle getting a spurious signal
late cleanly? How does it know which transaction the signal was for?
Alternatively we could have the deadlock timer reset all the time and
fire repeatedly. Then we could just have all backends ignore the
deadlock if they're not the lowest priority session in the cycle. But
this depends on everyone knowing everyone else's priority (and having
a consistent view of it).
--
greg