On Mon, Mar 2, 2009 at 1:22 PM, Brian Cox <brian.cox@xxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
