Re: granularity of locks in postgresql

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)

In response to

Browse pgsql-hackers by date

  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