Re: tablelevel and rowlevel locks - Mailing list pgsql-hackers

From Tom Lane
Subject Re: tablelevel and rowlevel locks
Date
Msg-id 11037.1062716881@sss.pgh.pa.us
Whole thread Raw
In response to tablelevel and rowlevel locks  ("Jenny -" <nat_lazy@hotmail.com>)
List pgsql-hackers
[ pgsql-general removed from cc list, as this is quite inappropriate
there ]

"Jenny -" <nat_lazy@hotmail.com> writes:
> I am working on a project that involves displaying locking information about 
> each lock taken, whether it be a row level or  table leve llock.
> When dealing with struct LOCK (src/include/storage) i have noticed that 
> postgreSQL creates a single LOCK  struct for each table in the  db. Like if 
> i acquire 2 seperate row level locks on 2 seperate rows, both these locks 
> are represented in the same struct LOCK datastructure .

As has been pointed out to you several times already, the LOCK
structures aren't used for row-level locks.  The objects that you are
looking at represent table-level locks.  For example, afterBEGIN;SELECT * FROM foo WHERE id IN (1,2) FOR UPDATE;

there will be a table-level AccessShareLock on "foo" that was acquired
(and not released) by the SELECT statement as a whole.  If there
actually were rows matching the WHERE clause, the locks on them are
represented by modifying their tuple headers on-disk.  There is nothing
about individual rows in the LOCK table.

Now, if you have modified the code with the intention of creating LOCK
entries for row-level locks, then all I can say is you didn't do it
right.  The LockTag created to represent a row-level lock should be
distinct from a table-level LockTag (or a page-level LockTag for that
matter).  If it is, the hash table will definitely store it as a
separate object.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Stats Collector Error 7.4beta1 and 7.4beta2
Next
From: Andrew Dunstan
Date:
Subject: Re: Win32 native port