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

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> >> it'd just take a few more processes. The issue is that you are
> >> expecting the lock manager to detect or not detect deadlock, when you
> >> still have some lock requests up your sleeve that it's not seen yet.
> >> As long as you can block before presenting them all, it can never work.
>
> > I know there has been talk about having this done in the lock manager,
> > and I know it isn't worth the effort, but I am wondering how you would
> > do it even if you were doing in the lock manager with more information
> > available.
>
> I'd have to go back and study my 1980's-vintage operating system theory
> textbooks before answering that ;-). But acquisition of multiple locks
> is a solved problem, AFAIR.
>
> Likely we'd have to throw out the existing lockmanager datastructures
> and start fresh, however --- they assume that a proc waits for only one
> lock at a time. It'd be a nontrivial bit of work.

Oh, OK. Just checking. It seems the starvation problem kept hitting us
as soon as we fixed the deadlock, cycling problem, and I was wondering
if there even was a solution. My guess is that you would have to put
the multi-lock request in several lock queues and make sure they all got
done at some point. A mess.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026