Re: Performance on DISABLE TRIGGER
| От | David Steele |
|---|---|
| Тема | Re: Performance on DISABLE TRIGGER |
| Дата | |
| Msg-id | 54F26DC2.6010909@pgmasters.net обсуждение исходный текст |
| Ответ на | Performance on DISABLE TRIGGER (gmb <gmbouwer@gmail.com>) |
| Ответы |
Re: Performance on DISABLE TRIGGER
|
| Список | pgsql-general |
On 2/27/15 9:07 AM, gmb wrote: > Hi all > > I'm doing some maintenance - which is done quite often, never had this > problem before - which requires me to disable triggers, run some updates and > then re-enable the triggers. > Where the whole process normally take 30 sec , it took much longer today and > I cancelled after 5 minutes. > > After running the statements individually to pinpoint the issue , I > identified that the problem is on the first line. > >> ALTER TABLE tab DISABLE TRIGGER trig; > I have not been able to run this successfully -- after 10 minutes the > connection ( to remote DB ) got severed . > Any ideas on where I can start to look for the cause of the problem ? ALTER TABLE requires an exclusive lock - my guess is that another process has a lock on the table. It could even be a select. pg_locks is your friend in this case: http://www.postgresql.org/docs/9.4/static/view-pg-locks.html -- - David Steele david@pgmasters.net
Вложения
В списке pgsql-general по дате отправления: