Jan Wieck wrote:
>
> Third we need an internal list of triggers that must be
> invoked later because at the time an event occured where they
> should have been triggered, they appeared in the other list
> and their execution is delayed until transaction end or
> explicit execution. This list must remember the OID of the
> trigger to invoke (to identify the procedure and the
> arguments), the relation that caused the trigger and the
> CTID's of the OLD and NEW row.
>
> That last list could grow extremely! Think of a trigger
> that's executing commands over SPI which in turn activate
> deferred triggers. Since the order of trigger execution is
> very important for RI, I can't see any chance to
> simplify/condense this information. Thus it is 16 bytes at
> least per deferred trigger call (2 OID's plus 2 CTID's). I
> think one or more temp files would fit best for this.
>
> A last tricky point is if one of a bunch of deferred triggers
> is explicitly called for execution. At this time, the entries
> for it in the temp file(s) must get processed and marked
> executed (maybe by overwriting the triggers OID with the
> invalid OID) while other trigger events still have to get
> recorded.
I believe that things are much simpler.
For each deferable constraint (trigger) we have to remember
the LastCommandIdProccessedByConstraint. When the mode of
a constraint changes from defered to immediate (SET CONSTRAINT MODE),
modified tuple will be fetched from WAL from down to up until
tuple modified by LastCommandIdProccessedByConstraint is fetched
and this is show stopper. Now we remember CommandId of
SET CONSTRAINT MODE as new LastCommandIdProccessedByConstraint.
When LastCommandIdProccessedByConstraint is changed by
SET CONSTRAINT MODE DEFERRED we remeber this in flag to
update LastCommandIdProccessedByConstraint later with higher
CommandId of first modification of triggered table (to reduce
amount of data to read from WAL).
?
Vadim
