From: Tom Lane <tgl@sss.pgh.pa.us>
To: Brian Cox <brian.cox@ca.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: "slow" queries
Date: Sun, 01 Mar 2009 12:05:51 -0500
Message-ID: <12688.1235927151@sss.pgh.pa.us> (raw)
In-Reply-To: <49A9F834.8060100@ca.com>
References: <49A9F834.8060100@ca.com>
Brian Cox <brian.cox@ca.com> writes:
> Actually, they're all deadlocked. The question is why?
Probably because the DROP is trying to acquire exclusive lock on its
target table, and some other transaction already has a read or write
lock on that table, and everything else is queuing up behind the DROP.
It's not a true deadlock that is visible to the database, or else
Postgres would have failed enough of the transactions to remove the
deadlock. Rather, what you've got is some very-long-running transaction
that is still making progress, or else is sitting idle because its
client is neglecting to close it; and everything else is blocked behind
that.
If it is not clear to you exactly who is waiting for what, a look into
the pg_locks view might help.
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, brian.cox@ca.com
Subject: Re: "slow" queries
In-Reply-To: <12688.1235927151@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