Re: Revised Patch to allow multiple table locks in "Unison"

Bruce Momjian wrote:
>
> The unusual case here is that deadlock is not checked on request, but
> only after waiting on the lock for a while.  This is because deadlock
> detection is an expensive operation.

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.


> In fact, you don't want deadlock
> detection in this case because LOCK a,b could be evaluated as a,b or b,a
> and you don't want it to fail randomly with deadlock messages.
>

It does not change the deadlock scenario at all.  It is still determined
by the resources in a previous (independent) LOCK statement and the ones
on
this LOCK statement (being it multiple or not) to be crossed.

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.


--
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9