tablelevel and rowlevel locks

On Thu, Sep 04, 2003 at 08:56:31AM -0700, Jenny - wrote:

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.

I think the locks would actually by represented by PROCLOCK structures.
The LOCK structures are for lockable objects, not for actual locks.

--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"Vivir y dejar de vivir son soluciones imaginarias.
La existencia est��� en otra parte" (Andre Breton)

On Thu, Sep 04, 2003 at 08:56:31AM -0700, Jenny - wrote:

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.

I think the locks would actually by represented by PROCLOCK structures.
The LOCK structures are for lockable objects, not for actual locks.

Well,from what i understand, PROCLOCK stores the TransactionID and the LOCK
its holding lock on ,so
how would PROCLOCK be holding the 'actual' lock as apposed to the lockable
objects?
thanks!

_________________________________________________________________
Use custom emotions -- try MSN Messenger 6.0!
http://www.msnmessenger-download.com/tracking/reach_emoticon

On Thu, Sep 04, 2003 at 11:21:05AM -0700, Jenny - wrote:

I think the locks would actually by represented by PROCLOCK structures.
The LOCK structures are for lockable objects, not for actual locks.

Well,from what i understand, PROCLOCK stores the TransactionID and the LOCK
its holding lock on ,so how would PROCLOCK be holding the 'actual' lock as
apposed to the lockable objects?

Huh... look at http://developer.postgresql.org/pdf/internalpics.pdf pages 61 and 63.
Maybe it's clearer than whatever I can say. Note that "HOLDER" has been renamed
to "PROCLOCK".

Anyway, I think the LOCK structure represents something that can be locked.
The PROCLOCK struct represents that some process is holding a lock on said
object. That may be the reason why you are seeing that a lock is held by more
than one process at the same time (while in fact some of them are probably
_waiting_ for the lock).

--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"I dream about dreams about dreams", sang the nightingale
under the pale moon (Sandman)

[ 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, 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

Alvaro Herrera Munoz <alvherre@dcc.uchile.cl> writes:

Anyway, I think the LOCK structure represents something that can be locked.

Right.

The PROCLOCK struct represents that some process is holding a lock on said
object.

IIRC, a PROCLOCK is created as soon as some backend tries to lock some
lockable object. So the PROCLOCK may only indicate that that backend is
waiting for a lock on that object, not that it already has one.

That may be the reason why you are seeing that a lock is held by more
than one process at the same time (while in fact some of them are probably
_waiting_ for the lock).

Also keep in mind that we use a lot of sharable lock modes --- so it's
entirely likely that multiple processes actually do have locks on the
same object. That's not wrong if their lock modes don't conflict.

regards, tom lane