rihad wrote:
Hi,
I've come across a strange deadlock that I need your help with. There
are two copies of the same Perl daemon running on a 2 cpu box. The
program is pretty simple (because I wrote it :)) so I can trace its
pathway fairly well: in it, there's a single "LOCK table foo" occurring
part way through a transaction that sometimes ends up as this:
DETAIL: Process 91376 waits for AccessExclusiveLock on relation 16488
of database 16386; blocked by process 92387.
Process 92387 waits for AccessExclusiveLock on relation 16488 of
database 16386; blocked by process 91376.
If there are only two processes, and each is waiting for an ACCESS
EXCLUSIVE lock on the same relation and being blocked by the other one,
then presumably both have weaker locks that conflict with ACCESS
EXCLUSIVE on that relation.
Process 1 can't proceed with the ACCESS EXCLUSIVE lock because process 2
has a lesser lock on the table.
Process 2 can't proceed with the ACCESS EXCLUSIVE lock because process 1
has a lesser lock on the table.
Deadlock.
I don't see any other way the situation could arise, but I'm *very* far
from an expert.
Indeed, there is one SELECT and, conditionally, one UPDATE before the
exclusive LOCK, on the table. I've re-read the manual, particularly this
line:
"One should also ensure that the first lock acquired on an object in a
transaction is the highest mode that will be needed for that object."
Since SELECT & UPDATE come before LOCK on bw_pool, the bug is obvious.
Sadly I can't use any other locking as I need exclusive access to OS's
firewall after getting bw_id. Well, I thought I'd move LOCK further away
inside the transaction to better mimic fine-grained locking. So one
solution is to move it back to the beginning.
Thank you!
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
