Thread: Triggers and transactions

Triggers and transactions

From
Craig James
Date:
If I drop and then recreate a trigger inside of a single transaction, how does it affect other processes trying to use the same table?  Can they just merrily go along their way using the table, or will they be blocked by an exclusive lock?

We have a trigger that detects illegal drugs and dangerous chemicals (such as explosives and flammable compounds that can't be shipped by air).  It's implemented as a trigger to ensure that even improperly coded application software can't accidentally let a customer order a prohibited compound.

Unfortunately, the trigger's function is necessarily "heavyweight" and slow.

The drop-and-restore-trigger operation is needed when we're copying data one server to another.  Since the data on the primary source have already been checked, there's no need to let the trigger re-check every row.  When I drop-and-recreate the trigger for the duration of a COPY operation, it speeds the operation from (for example) 30 minutes to 15 seconds.

But if the drop-and-restore-trigger operation blocks all access to the tables, that's a problem.

Thanks,
Craig

Re: Triggers and transactions

From
Richard Huxton
Date:
On 28/01/13 18:54, Craig James wrote:
> If I drop and then recreate a trigger inside of a single transaction,
> how does it affect other processes trying to use the same table?  Can
> they just merrily go along their way using the table, or will they be
> blocked by an exclusive lock?
>
I *think* it blocks, but in any case, read on...

> We have a trigger that detects illegal drugs and dangerous chemicals
> (such as explosives and flammable compounds that can't be shipped by air).

<pedantry mode="full">detects a reference to illegal... (unless you've
hooked your RDBMS up to some sort of x-ray scanner, in which case I
salute you sir)</pedantry>

> Unfortunately, the trigger's function is necessarily "heavyweight" and
> slow.
>
> The drop-and-restore-trigger operation is needed when we're copying
> data one server to another.

Run the copy as a different user than ordinary applications (a good idea
anyway). Then the function can just check current_user and exit for the
copy.

--
   Richard Huxton
   Archonet Ltd


Re: Triggers and transactions

From
Rosser Schwarz
Date:
On Mon, Jan 28, 2013 at 10:54 AM, Craig James <cjames@emolecules.com> wrote:
But if the drop-and-restore-trigger operation blocks all access to the tables, that's a problem.

Were the triggers in question created with "CREATE CONSTRAINT TRIGGER"?  If not, "ALTER TABLE foo DISABLE TRIGGER USER" may do what you need here.

rls

--
:wq