Re: this is in plain text (row level locks) - Mailing list pgsql-hackers

From Sailesh Krishnamurthy
Subject Re: this is in plain text (row level locks)
Date
Msg-id bxyfzkwwwwa.fsf@datafix.cs.berkeley.edu
Whole thread Raw
In response to Re: this is in plain text (row level locks)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: this is in plain text (row level locks)  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
   Tom> "Jenny -" <nat_lazy@hotmail.com> writes:   >> Iam trying to acquire rowlevel locks in postgresql. I try doing
>>this: 'select * from students where name='Larry' for update;   >> But by looking at the holding array of proclock ,
I'venoticed   >> that by doing this only AccessShareLock gets acquired which is   >> a table level lock.
 
   Tom> Row-level locks are not recorded in proclock --- they are   Tom> implemented by marking the individual tuple
on-disk. If we   Tom> tried to record them in shared memory, it'd be very easy to   Tom> run out of shared memory,
becauseyou could be holding row   Tom> locks on a large number of tuples.
 

Of course, other database systems do this without too much hassle
.. including relying on lock escalation (move up to page/table level
locks) when the number of locks grow too large. 

Does pgsql only record X locks on the individual tuples on-disk or
does it do so for S locks as well ? 

Not that I dislike the idea - Toby Lehman suggested this in his
Ph.D. thesis in the mid-eighties for main-memory databases (where you
don't take the write penalty).

-- 
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: this is in plain text (row level locks)
Next
From: Bruce Momjian
Date:
Subject: Re: this is in plain text (row level locks)