deadlock

From: rihad <rihad(at)mail(dot)ru>
To: pgsql-general(at)postgresql(dot)org
Subject: deadlock
Date: 2008-04-03 16:29:27
Message-ID: 47F505E7.1070508@mail.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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.

After the exclusive lock, there is also exactly one SELECT, and then one
UPDATE query involving table foo, among others, doing their usual
implicit locking on it. I've read in the manuals that it's okay to stack
locks this way as long as the more restrictive locks precede less
restrictive ones. Mind you, there may be many requests per second, and
some of them can and will happen at the same wall clock time due to 2
cpus at work. Can locking break under these circumstances? I'd rather
opt for an educated solution to this, than having to check and restart
the query.

PostgreSQL 8.3.1
FreeBSD 7.0
p5-DBI-1.60.1
p5-DBD-Pg-1.49

Thanks for any tips.

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ron Mayer 2008-04-03 16:31:01 Re: modules
Previous Message Mark Mielke 2008-04-03 16:28:40 Re: [GENERAL] SHA1 on postgres 8.3