Re: [GENERAL] Cascades Failing - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] Cascades Failing
Date
Msg-id 1230.1124204428@sss.pgh.pa.us
Whole thread Raw
Responses Re: [GENERAL] Cascades Failing  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
List pgsql-hackers
[ redirected to -hackers ]

I wrote:
> This suggests that we need a way to prevent immediate execution of
> freshly queued triggers at the end of a command fired by an FK trigger.
> If we could move them to the end of the trigger queue that the FK
> operation itself is in, things would work reasonably well I think.

After a quick look through the code, it seems like the way to do this
is to add an extra bool parameter "nest_triggers" to _SPI_pquery, which
when false would simply suppress its calls to AfterTriggerBeginQuery
and AfterTriggerEndQuery --- thus causing any queued triggers to be
queued in the same trigger list the FK is in.  We'd then expose this
parameter (only) via SPI_execute_snapshot, which is intended only for
RI trigger use anyway.

I think this would take some generalization of afterTriggerInvokeEvents,
which now might or might not find the target rel in the EState it's
passed, but otherwise it doesn't seem too invasive.  Thoughts?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Testing of MVCC
Next
From: Andrew Dunstan
Date:
Subject: Re: Testing of MVCC