Re: Bug in FOREIGN KEY - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: Bug in FOREIGN KEY
Date
Msg-id 200012141202.HAA03905@jupiter.jw.home
Whole thread Raw
In response to Re: Bug in FOREIGN KEY  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Bug in FOREIGN KEY  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Bug in FOREIGN KEY  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Bug in FOREIGN KEY  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian wrote:
> > Bruce Momjian writes:
> >
> > > ERROR:  triggered data change violation on relation "primarytest2"
> >
> > We're getting this report about once every 48 hours, which would make it a
> > FAQ.  (hint, hint)
> >
>
>
> First time I heard of it.  Does anyone know more details?
   Think  I misinterpreted the SQL3 specs WR to this detail. The   checks must be made per statement,  not  at  the
transaction  level.  I'll  try  to fix it, but we need to define what will   happen with referential actions in the
case of  conflicting   actions on the same key - there are some possible conflicts:
 
   1.  DEFERRED ON DELETE NO ACTION or RESTRICT
       Do  the referencing rows reference to the new PK row with       the  same  key  now,  or  is  this  still  a
constraint      violation?  I  would say it's not, because the constraint       condition is satisfied at the end of
thetransaction. How       do other databases behave?
 
   2.  DEFERRED ON DELETE CASCADE, SET NULL or SET DEFAULT
       Again  I'd  say  that  the  action  should  be suppressed       because a matching PK row is present at
transactionend -       it's  not  the same old row, but the constraint itself is       still satisfied.
 
   Implementing it that way (if it is correct that way) requires   that  the  RI-triggers  check that the key in
questionreally   disappeared from the PK table,  at  least  for  the  deferred   invocation at transaction end. This
lookupis not required in   the immediate case, so it would be  possible  to  retain  the   current  performance  here,
but we'd  need a mechanism that   tells the trigger if it is actually invoked in  immediate  or   deferred mode. Don't
knowhow to do that right now.
 
   To  fix  it now, I'd tend to remove the triggered data change   check in the trigger queue (where the error is
coming from)   and  add  the  extra  PK lookup to the triggers for 7.1. Then   think about the suppress of  it  with
an immediate/deferred   flag mechanism for 7.2.
 


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #




pgsql-hackers by date:

Previous
From: Denis Perchine
Date:
Subject: vacuum verbose analyze lazy problem.
Next
From: Luis Sousa
Date:
Subject: Ocasional problems !!!!