On Mon, Mar 2, 2009 at 1:22 PM, Brian Cox <brian.cox@ca.com> wrote:
> As you can see there are only 3 transactions and 1 starts 1 hour after
> the drop begins. I'm still trying to figure out how to interpret the
> pg_locks output, but (presumably) you/others on this forum have more
> experience at this than I.
I'm rather suspicious of that line that says <IDLE> in transaction.
Connections that are idle, but in a transaction, can be holding locks.
And since they are idle, things can stay that way for a very long
time... hours, days... coincidentally, that idle-in-transaction
procpid is holding AccessShareLocks on a whole boatload of relations.
It's a little hard to decode this output because the "relation" column
from pg_locks is an OID, and we don't know what relation it
represents. It's helpful to cast that column to "regclass": select
locktype,database,relation::regclass,virtualxid,virtualtransaction,pid,mode
from pg_locks order by mode;
For now, though, try this:
select oid, relname from pg_class where relname like 'ts_defects%';
I suspect you'll find that the oid of the table that you were trying
to drop is one of the ones on which the idle in transaction process is
holding an AccessShareLock on...
...Robert
