Re: this is in plain text (row level locks)
От | Sailesh Krishnamurthy |
---|---|
Тема | Re: this is in plain text (row level locks) |
Дата | |
Msg-id | bxyfzkwwwwa.fsf@datafix.cs.berkeley.edu обсуждение исходный текст |
Ответ на | Re: this is in plain text (row level locks) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: this is in plain text (row level locks)
|
Список | 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 по дате отправления: