From: | Bèrto ëd Sèra <berto(dot)d(dot)sera(at)gmail(dot)com> |
---|---|
To: | Jerry Sievers <gsievers19(at)comcast(dot)net> |
Cc: | Rural Hunter <ruralhunter(at)gmail(dot)com>, pgsql-admin(at)postgresql(dot)org, Kevin Grittner <kevin(dot)grittner(at)wicourts(dot)gov> |
Subject: | Re: lock problem |
Date: | 2011-12-21 15:40:35 |
Message-ID: | CAKwGa__-7ncap5sji9x0=3g5V=Fv1cpZYGO5bKDHgxeT6z9rzg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Rural Hunter | 2011-12-21 16:02:59 | Re: lock problem |
Previous Message | Jerry Sievers | 2011-12-21 15:25:24 | Re: lock problem |