Skip site navigation (1) Skip section navigation (2)

Re: Behavior of shared/exclusive row locks

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Behavior of shared/exclusive row locks
Date: 2005-04-27 22:14:15
Message-ID: 20050427221415.GB8500@dcc.uchile.cl (view raw or flat)
Thread:
Lists: pgsql-hackers
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)

In response to

pgsql-hackers by date

Next:From: Hannu KrosingDate: 2005-04-27 22:22:55
Subject: Re: Tablepartitioning: Will it be supported in Future?
Previous:From: Tom LaneDate: 2005-04-27 21:51:47
Subject: Re: Behavior of shared/exclusive row locks

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group