Re: [HACKERS] Re: Referential Integrity In PostgreSQL - Mailing list pgsql-hackers

From Vadim Mikheev
Subject Re: [HACKERS] Re: Referential Integrity In PostgreSQL
Date
Msg-id 37E7A0F6.9B9E8EC0@krs.ru
Whole thread Raw
In response to Re: Referential Integrity In PostgreSQL  (wieck@debis.com (Jan Wieck))
Responses Re: [HACKERS] Re: Referential Integrity In PostgreSQL
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: wieck@debis.com (Jan Wieck)
Date:
Subject: Re: [HACKERS] Re: Referential Integrity In PostgreSQL
Next
From: Thomas Lockhart
Date:
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2]