Fernando Nasser <fnasser@redhat.com> writes:
> But that is what happens. If one of the locks is not obtained, the
> algorithm does wait on that lock (after releasing the other locks).
> In the case of a deadlock (tom's scenario #1) it would wait forever,
> but the deadlock detection will find it in there and break it.
I'm entirely unconvinced of that. My example #2 shows that it's
possible for two multi-lock statements to bounce back and forth between
failed conditional-lock attempts, never doing a hard wait that would
allow the lock manager to detect deadlock. That simple example requires
somewhat-implausible assumptions about relative process speed, but I
think that more complex cases might exhibit similar behavior that is
less dependent on precise timing. (The fact that I have not come up with
one after a few minutes' thought can hardly be taken as proof that there
are no such cases.)
Basically, my objection here is that the proposed implementation tries
to avoid telling the lock manager what is going on. Since the lock
manager has sole responsibility for detecting deadlock, it can't
possibly be a good idea not to give it complete information.
> And deadlock failures will be intermittent anyway. A potential deadlock
> condition may or may not happen each time depending on the interleaving
> of execution of the two processes.
Of course. The point is that we currently offer a guarantee that when a
deadlock does occur, it will be detected, reported, and recovered from
(by rolling back one or more of the conflicting transactions). I am
afraid that the proposed multi-LOCK implementation will break that
guarantee. I do not think the proposed feature is sufficiently valuable
to justify taking any such risk.
regards, tom lane