Re: Behavior of shared/exclusive row locks

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.
(Tom Lane)