Hello,

I have two concurrent transactions, both heavy R/W type things. I now see that
one is backed up behind in the other, and pg_locks shows me this:

sep=# select locktype, transactionid, transaction from pg_locks where not
granted;
locktype | transactionid | transaction
---------------+---------------+-------------
transactionid | 3391481 | 3391528
(1 row)


The TFM tells me (in the description of pg_locks):

"Every transaction holds an exclusive lock on its transaction ID for its
entire duration. If one transaction finds it necessary to wait specifically
for another transaction, it does so by attempting to acquire share lock on
the other transaction ID. That will succeed only when the other transaction
terminates and releases its locks."

So what could make my transaction decide to wait for that other tx? I've
checked to see that all updates to rows shared by the two transactions are
done late in the process, but this lock happens almost immediately after the
second tx starts...

Comments?

jan

--
--------------------------------------------------------------
Jan de Visser * * * * * * * * * * jdevisser@digitalfairway.com

* * * * * * * * Baruk Khazad! Khazad ai-menu!
--------------------------------------------------------------

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Jan de Visser <jdevisser@digitalfairway.com> writes:
> So what could make my transaction decide to wait for that other tx?

Usually what this indicates is blocking to acquire a row-level lock,
eg that transaction is waiting to see if it can update a row that the
other one already updated. In 8.1 and later you can find out which row
is contended for by seeing what row-level lock is held by the *waiting*
transaction (yes, really, not the waited-for one).

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq