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

> Bruce Momjian <pgman@candle.pha.pa.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@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026