Re: Performance on DISABLE TRIGGER

From: David Steele <david(at)pgmasters(dot)net>
To: gmb <gmbouwer(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Performance on DISABLE TRIGGER
Date: 2015-03-01 01:39:14
Message-ID: 54F26DC2.6010909@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)pgmasters(dot)net

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message tpham 2015-03-01 02:02:10 Re: [postgresql 9.3.5] autovacuums stuck on non-existent pg_toast tables
Previous Message Adrian Klaver 2015-02-28 22:14:50 Re: Application written in pure pgsql, good idea?