Brian Cox <brian.cox@xxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
