>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? I also don't understand why inserts into a separate partition or a select on an unrelated table should cause any locks on the table being dropped in the 1st place. I assume that the CREATE VIEW, which started 1 hour after the DROP, can't possibly be the cause of this "deadlock". Brian
