> Phil Endecott <spam_from_postgresql_general@xxxxxxxxxxxx> writes:
>> I would understand this if I were doing an "ALTER TABLE", for example.
>> But does adding or removing a trigger really count as "schema-altering"?
>
> [ shrug... ] Hard to say. Probably depends a lot on what the trigger
> does. I suppose we could at least reduce the lock from AccessExclusive
> to Exclusive, which would allow concurrent readers (since SELECT by
> definition doesn't fire any triggers).
>
> No one's really gone through and taken a hard look at whether every
> single DDL operation needs the maximum lock ...
>
> regards, tom lane
>
FYI, I did experience locking issues (my attempt to drop the trigger
resulted in other sessions blocking)...
In any event, I found a solution which at first seemed stupid, but works
so great I thought I'd share it...
All I did was added an extra column to my table "batch_process". Then in
the trigger do something like:
IF NEW.batch_process THEN
NEW.batch_process := NULL;
RETURN NULL;
END IF;
.. whatever the rest of transaction is
Then when doing an insert, just:
INSERT INTO table (..., batch_process) VALUES (..., 't') when you want the
trigger not to fire...
What do you guys think?.. Is this dumb?....
- Greg
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
