Thanks for the quick reply Tom! The pg_locks table helped me to get to the bottom of this. For future reference to others, here is a good way to view the pg_locks table for a particular database, adding table name annotation: SELECT pg_locks.*, pg_class.relname from pg_locks, pg_class WHERE pg_locks.relation=pg_class.oid and pg_locks.database= (SELECT datid from pg_stat_database where datname = 'my_db_name'); Mike Tom Lane wrote: > Mike Charnoky <noky@xxxxxxxxxxx> writes: >> First, a question: For a PG8.1 database, is it preferable to use the new >> "alter table disable|enable trigger" command as opposed to the old >> method of setting pg_class.reltriggers = 0? > > Very much so --- manual manipulation of reltriggers has never been > anything but a dangerous kluge. > >> I'm assuming the "alter table" approach is preferred, so I converted >> some scripts to use the new method. However, sometimes the >> enable/disable trigger command hangs when operating on certain tables. >> I use the syntax "ALTER TABLE mytable DISABLE TRIGGER ALL;". Any hints >> on how to debug this? > > Look in pg_locks to see who's got a lock on the table. One of the > reasons the pg_class update is a kluge is exactly that it ignores > locking considerations ... > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org/
