On Wed, Apr 27, 2005 at 05:51:47PM -0400, Tom Lane wrote:
> Suppose that we redo the LOCKTAGs per previous discussion (which I would
> like to do anyway), so that it is possible to define an lmgr lock on a
> particular tuple.
Hm. If you want I can give you the part of the patch that dealt with
changing LOCKTAG. It's not a big deal but it might save you some
effort. (On the other hand, if you want to do a wholesale revamp of
LOCKTAG, it will only slow you down.)
> The objection to this was that there could be too
> many locks held for lmgr to cope, but your idea above shows the way out.
> Once a backend realizes that it's got to wait for a tuple, it releases
> the page context lock and then gets the lmgr lock representing the
> target tuple, with either a shared or exclusive lock mode as
> appropriate. After it gets that, it waits on the current tuple holder
> as in your patch. After it gets that, it updates the tuple state as
> needed, and only then releases the lmgr lock.
> A backend that thinks it can join an existing shared locker also has to
> get the lmgr lock in the same way, so that it will block if there is
> a pending exclusive locker.
Sounds like an excellent plan to me.
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
Essentially, you're proposing Kevlar shoes as a solution for the problem
that you want to walk around carrying a loaded gun aimed at your foot.
In response to
pgsql-hackers by date
|Next:||From: Hannu Krosing||Date: 2005-04-27 22:22:55|
|Subject: Re: Tablepartitioning: Will it be supported in Future?|
|Previous:||From: Tom Lane||Date: 2005-04-27 21:51:47|
|Subject: Re: Behavior of shared/exclusive row locks |