pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Cox, Brian <Brian.Cox@ca.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: "slow" queries
Date: Sun, 01 Mar 2009 20:57:34 -0500
Message-ID: <18268.1235959054@sss.pgh.pa.us> (raw)
In-Reply-To: <D181508F0DF4C247B57FDD88B342C110046DC10E@USILMS11.ca.com>
References: <49A9F834.8060100@ca.com>
	<12688.1235927151@sss.pgh.pa.us>
	<D181508F0DF4C247B57FDD88B342C110046DC10E@USILMS11.ca.com>

"Cox, Brian" <Brian.Cox@ca.com> writes:
>> 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.

> This "deadlock" finished after 18h and 48m. As there is only 1 select
> on a table with 400 rows and 10 inserts into a separate partition than
> the one being dropped, what could possible take 18:48 to do?

[ shrug... ]  You tell us.  To me it sounds a whole lot like some client
program sitting on an open transaction that has a nonexclusive lock on
the table to be dropped.  That transaction wasn't necessarily doing any
useful work; it might have just been waiting on the client.

At this point I suppose arguing about it is moot because the evidence
is all gone.  If it happens again, capture the contents of pg_locks and
pg_stat_activity while things are still stuck.

			regards, tom lane




view thread (14+ messages)  latest in thread

Message-ID: <18268.1235959054@sss.pgh.pa.us>
Permalink:  ../18268.1235959054@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/18268.1235959054@sss.pgh.pa.us

 · 

reply

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: <18268.1235959054@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