From: | Bill Moseley <moseley(at)hank(dot)org> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Tracking down a deadlock |
Date: | 2009-05-05 00:42:57 |
Message-ID: | 20090505004256.GA2312@hank.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I seemed to have resolved this issue by a:
LOCK TABLE account IN EXCLUSIVE MODE;
at the very start of the transaction to prevent that transaction
from running in parallel.
The transaction has quite a few selects and inserts and a few updates.
I was hoping to not lock at the start of the transaction which will
effectively serialize that code.
The update that was causing the deadlock was just about the last
command in the transaction. Removing that update and the deadlocks
go away.
I had hoped that a LOCK near the end of the transaction (before that UPDATE
that deadlocks) would work. Oddly, it didn't and the deadlock was reported
then on the LOCK itself, plus my deadlock_timeout (60 seconds) didn't seem to
apply in that case. A mystery.
Thanks for the help,
--
Bill Moseley.
moseley(at)hank(dot)org
Sent from my iMutt
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2009-05-05 03:17:24 | Re: Tracking down a deadlock |
Previous Message | Tom Lane | 2009-05-04 23:51:39 | Re: Calculating product from rows - (aggregate product ) |