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.
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
