Message-ID: <4EF20333.8020404@gmail.com>
Date: Thu, 22 Dec 2011 00:02:59 +0800
From: Rural Hunter <ruralhunter@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
 rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: =?UTF-8?B?QsOocnRvIMOrZCBTw6hyYQ==?= <berto.d.sera@gmail.com>
CC: pgsql-admin@postgresql.org, Kevin Grittner <kevin.grittner@wicourts.gov>,
	Jerry Sievers <gsievers19@comcast.net>
Subject: Re: lock problem
References: <4EF18A8A0200002500043F0A@gw.wicourts.gov>
	<CAKwGa_-C0Gcp2PaNWS9_kq0nz7KfcbV8hb5XYmxzUyHNt6AF-w@mail.gmail.com>
	<4EF1F027.507@gmail.com> <87aa6m7xqz.fsf@comcast.net>
	<CAKwGa__-7ncap5sji9x0=3g5V=Fv1cpZYGO5bKDHgxeT6z9rzg@mail.gmail.com>
In-Reply-To: 
 <CAKwGa__-7ncap5sji9x0=3g5V=Fv1cpZYGO5bKDHgxeT6z9rzg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

well, thanks. I checked the application and found there was a bug 
causing many queries were updating the same row. However, those updates 
are just single statement, no multi-statement transaction involved. So 
I still have this question:
same statement A,B,C,D update same row. The start order is A->B->C-D. 
 From what I've gotten, B/C/D got the lock before A.  Why did that 
happen?

于2011年12月21日 23:40:35,Bèrto ëd Sèra写到:
> 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.