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.