| From: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> | 
|---|---|
| To: | Jenny - <nat_lazy(at)hotmail(dot)com> | 
| Cc: | pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: granularity of locks in postgresql | 
| Date: | 2003-07-26 18:50:15 | 
| Message-ID: | 20030726185015.GC962@dcc.uchile.cl | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Sat, Jul 26, 2003 at 10:59:49AM -0700, Jenny - wrote:
> The following lines are from readme file present in the 
> \src\backend\storage\lmgr folder of postgresql
> 
> "If we are setting a table level lock
> Both the blockId and tupleId (in an item pointer this is called
> the position) are set to invalid, if it is a page level lock the
> blockId is valid, while the tupleId is still invalid.  Finally if
> this is a tuple level lock (we currently never do this) then both
> the blockId and tupleId are set to valid specifications."
> I dont see any field called tupleId in LockTag..does it have another name?
I think the tupleId is actually represented by the pair
BlockNumber blkno, OffsetNumber offno
> Also, "(we currently never do this)"--> does this mean that we currently 
> can acquire tuplelevel(row level) locks in postgresql?
It should work, but think about memory requirements if you want to
acquire a lot of those.
-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Those who use electric razors are infidels destined to burn in hell while
we drink from rivers of beer, download free vids and mingle with naked
well shaved babes." (http://slashdot.org/comments.pl?sid=44793&cid=4647152)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2003-07-26 20:40:27 | Re: parallel regression test failure | 
| Previous Message | Jenny - | 2003-07-26 18:47:51 | Identifying object locked |