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: | Raw Message | Whole Thread | 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 |