>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