Re: lock problem

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.

In response to

Responses

Browse pgsql-admin by date

  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