Re: Performance on DISABLE TRIGGER - Mailing list pgsql-general

From David Steele
Subject Re: Performance on DISABLE TRIGGER
Date
Msg-id 54F26DC2.6010909@pgmasters.net
Whole thread Raw
In response to Performance on DISABLE TRIGGER  (gmb <gmbouwer@gmail.com>)
Responses Re: Performance on DISABLE TRIGGER  (gmb <gmbouwer@gmail.com>)
List 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


Attachment

pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: Application written in pure pgsql, good idea?
Next
From: tpham
Date:
Subject: Re: [postgresql 9.3.5] autovacuums stuck on non-existent pg_toast tables