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