Re: Revised Patch to allow multiple table locks in "Unison" - Mailing list pgsql-patches

From Tom Lane
Subject Re: Revised Patch to allow multiple table locks in "Unison"
Date
Msg-id 1684.996725899@sss.pgh.pa.us
Whole thread Raw
In response to Re: Revised Patch to allow multiple table locks in "Unison"  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Revised Patch to allow multiple table locks in "Unison"  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-patches
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.

            regards, tom lane

pgsql-patches by date:

Previous
From: Barry Lind
Date:
Subject: Patch to improve commit time performance and a few other things
Next
From: Bruce Momjian
Date:
Subject: Re: Revised Patch to allow multiple table locks in "Unison"