Re: [GENERAL] Cascades Failing

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [GENERAL] Cascades Failing
Date: 2005-08-19 15:12:08
Message-ID: 20050819080428.I34168@megazone.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Fri, 19 Aug 2005, Tom Lane wrote:

> Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> > Is the correct answer to continue marking and running the triggers until
> > there are no immediate triggers left to run for this case?
>
> Hmm ... my recollection is that we put in the concept of marking because
> we needed it for correct behavior in some cases. I don't recall exactly
> why though.

The comment there talks about someone doing a set constraints immediate
inside a trigger function.

/*
* Process all immediate-mode triggers queued by the query, and
move
* the deferred ones to the main list of deferred events.
*
* Notice that we decide which ones will be fired, and put the
deferred
* ones on the main list, before anything is actually fired. This
* ensures reasonably sane behavior if a trigger function does
* SET CONSTRAINTS ... IMMEDIATE: all events we have decided to
defer
* will be available for it to fire.
*
* If we find no firable events, we don't have to increment
firing_counter.
*/

I think we were worried about it either skipping events or potentially
running events twice in that case, but I don't remember exactly either.

I'm not sure that looping would affect that though, it'd be basically
mark (0)
increment firing id (0->1)
run triggers using the old id (0)
- if the set constraints immediate was run here, it'd mark using the
- incremented id (hopefully incrementing again - will need to check) and
- run using that id (1->2) and (1)
mark (2)
increment firing id (2->3)
run triggers using (2)

There might be some other reason that's not enshrined in the comment
though.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adam Witney 2005-08-19 15:17:37 How to cancel a query if SIGINT does not work?
Previous Message Stephan Szabo 2005-08-19 15:03:39 Re: [GENERAL] BUG #1830: Non-super-user must be able to copy

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2005-08-19 16:14:33 Why is lock not released?
Previous Message Alvaro Herrera 2005-08-19 14:42:40 Re: obtaining row locking information