Re: this is in plain text (row level locks)

Sailesh Krishnamurthy wrote:
> >>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> Tom> "Jenny -" <nat_lazy(at)hotmail(dot)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've noticed
> >> 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, because you 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.

I wouldn't say they do it with little hassle --- it is quite a pain, in
fact, at least for users.

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

We don't need to shared lock individual rows because of MVCC --- well,
we sort of do by recording our xid in our proc structure, so folks don't
change things underneath us. We prevent expired rows from disappearing
from the disk by others looking at our proc start xid.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073