Re: lock problem - Mailing list pgsql-admin

From Bèrto ëd Sèra
Subject Re: lock problem
Date
Msg-id CAKwGa__-7ncap5sji9x0=3g5V=Fv1cpZYGO5bKDHgxeT6z9rzg@mail.gmail.com
Whole thread Raw
In response to Re: lock problem  (Jerry Sievers <gsievers19@comcast.net>)
Responses Re: lock problem  (Rural Hunter <ruralhunter@gmail.com>)
List pgsql-admin
Hi,
 
> I dig another case more and found something interesting. it's actually
> waiting for a lock of type transactionid. I ran the query below 3

Normal.  That's the kind of lock you are waiting for when some other
transaction has touched the same rows for update that you are
attempting.

Record level locks are stored on the records themselves, so you won't see them explicitly mentioned in views like pg_locks:
"Although tuples are a lockable type of object, information about row-level locks is stored on disk, not in memory, and therefore row-level locks normally do not appear in this view. If a transaction is waiting for a row-level lock, it will usually appear in the view as waiting for the permanent transaction ID of the current holder of that row lock."
 
See http://www.postgresql.org/docs/9.1/static/explicit-locking.html

Bèrto
--
==============================
If Pac-Man had affected us as kids, we'd all be running around in a darkened room munching pills and listening to repetitive music.

pgsql-admin by date:

Previous
From: Jerry Sievers
Date:
Subject: Re: lock problem
Next
From: Rural Hunter
Date:
Subject: Re: lock problem