Hm, in my experiments what's happening is that dropping a table needs an AccessExclusiveLock on the table and any open transactions that have read from that table will have at least an AccessShareLock on that table which blocks the schema change. But I don't think merely having a trigger will hold a lock. Will it? Anyone? I think you need an actual open transaction that has accessed the table. Is it possible you have some transactions that are live for an extended period? Either large queries that are still running or just some non-autocommit transaction sitting waiting for user input before committing? You could investigate by doing select * from pg_lock where not granted; Pick out the one looking for an AccessExclusiveLock, its pid should match the pid of the backend where you're doing the DROP. Look at the relation column and do select * from pg_lock where relation = NNN where NNN is the relation of the nongranted lock. Look at what type of lock is being held by that's blocking the partition drop and what the pid of those backends are. You can see what command they're executing by using a tool like pg_admin to look at the stats command buffer or just by looking at ps usually. 8.2 will allow you to move a partition out of an inheritance structure instead of dropping it entirely. Sadly it takes the same lock so it won't help you here. I wonder if it really needs such a strong lock. If it dropped the inheritance structure without locking it would open up some strange cases though. Like, you wouldn't know just because you had committed that other queries weren't still running that think your table is still a partition in the partitioned table. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
