[ pgsql-general removed from cc list, as this is quite inappropriate there ]
"Jenny -" <[EMAIL PROTECTED]> 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, after BEGIN; 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 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly