Re: tablelevel and rowlevel locks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jenny -" <nat_lazy(at)hotmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: tablelevel and rowlevel locks
Date: 2003-09-04 23:08:01
Message-ID: 11037.1062716881@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

[ pgsql-general removed from cc list, as this is quite inappropriate
there ]

"Jenny -" <nat_lazy(at)hotmail(dot)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, 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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Relaxin 2003-09-04 23:08:44 Re: Optimizer picks an ineffient plan
Previous Message Thomas Kellerer 2003-09-04 22:36:49 Re: Output from PLPGSQL

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-09-04 23:09:49 Warning for missing createlang
Previous Message elein 2003-09-04 22:50:33 Re: plpython