From: Tom Lane <tgl@sss.pgh.pa.us>
To: Greg Stark <gsstark@mit.edu>
Cc: Brendan Duddridge <brendan@clickspace.com>
Cc: PostgreSQL Performance <pgsql-performance@postgresql.org>
Subject: Re: App very unresponsive while performing simple update
Date: Sun, 28 May 2006 17:32:19 -0400
Message-ID: <159.1148851939@sss.pgh.pa.us> (raw)
In-Reply-To: <87slmum3th.fsf@stark.xeocode.com>
References: <961F6F02-4B00-494C-B071-6DF76A305C14@clickspace.com>
<21B15664-F4EE-462C-88B4-EEEB2B4A979F@clickspace.com>
<874pzanvk6.fsf@stark.xeocode.com>
<17733.1148832292@sss.pgh.pa.us>
<87slmum3th.fsf@stark.xeocode.com>
Greg Stark <gsstark@mit.edu> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> And what PG version is this? Alvaro fixed the
>> foreign-keys-take-exclusive-locks problem in 8.1 ...
> Except I don't think this is taking an exclusive lock at all. The original
> post had the deadlock detection fire on a SharedLock.
Yeah, but it was a ShareLock on a transaction ID, which is the trace
of something doing XactLockTableWait, which is only done if we're
blocking on a locked or updated-but-uncommitted row.
Since Brendan says he's using 8.1, the FK theory is out, and I think
what this probably is is a garden-variety deadlock on tuple updates, ie,
two concurrent transactions tried to update the same tuples in different
orders.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, gsstark@mit.edu, brendan@clickspace.com
Subject: Re: App very unresponsive while performing simple update
In-Reply-To: <159.1148851939@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox