Stephan Szabo <sszabo@xxxxxxxxxxxxxxxxxxxxx> writes:
> I think this is similar to the issue recently reported on -bugs. My
> theory there was that trigger timing changes between 7.4 and 8.0 seems to
> have caused the sequence of checks inside the trigger manager and triggers
> that prevented intermediate states from being checked to become broken.
Just looking at the example, I think that the issue is that we fire a
trigger for one of the FK constraints, it does an UPDATE to fix the
constraint it knows about, and then on the way out of that UPDATE
statement, check triggers for all of the FK constraints are executed
and the ones that haven't been fixed yet are unhappy. (The failure
occurs because two independent updates are needed on the same row of
the referencing table, and only one has been done yet.) So the problem
comes directly from the fact that FK triggers can fire at the ends of
nested statements, rather than only at the outer level as they did
before.
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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
