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

Bruce Momjian wrote:
>
> > Bruce Momjian wrote:
> > >

[snip]

> >
> > Deadlocks are not possible with this patch. The four conditions needed
> > for deadlock are (according to Operating Systems: Internals and Design
> > Principles, 4th Ed. by W. Stallings):
> >
> ...
> >
> > The patch code never holds any of requested locks, while waiting for a
> > locked relation to become free. If a lock on all tables in the lock list
> > cannot be acquired at once, it backs off and releases all locks.
> >
> > Stallings writes about preventing condition 3: "This condition can be
> > prevented in several ways. [. . .] [One way is to require that,] if a
> > process holding certain resources is denied a further request, that
> > process must release its original resources and, if necessary, request
> > them again together with the additional resources."
> >
> > This is exactly what the patch does. Observe that if one lock is not
> > available, the patch releases all locks so far acquired, and then
> > acquires
> > the locks again. Hence, condition 3 is prevented, and so deadlock is
> > prevented.
>
> Excellent point. I had not considered the fact that you don't hang
> waiting for the other locks; you just release them all and try again.
>

I have a question.
What will happen when the second table is locked for a long time
though the first table isn't locked ?

regards,
Hiroshi Ioue