Re: [HACKERS] Weired FK problem

Bruce Momjian wrote:

>
> Looks like it works.  I just tried a related item:
>
> >     Now the other way round:
> >
> >     (S1)    insert into t1 values (1);
> >     (S1)    begin;
>
> >     (S2)    delete from t1 where a = 1;
> >     (S1)    insert into t2 values (1);
>
> I swapped the above two items, and the INSERT properly failed the
> contraint.
>
> >
> >     (S2)    -- Session is now blocked
> >
> >     (S1)    commit;
> >
> >     (S2)    -- Session continues without error
>
> I was a little unsure how trigger visibility was going to handle cases
> where the constraint failure happened after the other transaction
> started, but it seems to work fine.

    I  already committed the visibility overriding by RI triggers
    for time qualification. Maybe you're seeing  the  results  of
    this little hack.

> It is only the trigger that has full visibility, not the statements in
> the query, right?

    That's  the  behaviour  I  wanted to get from it. RI triggers
    need to see what's committed and what their  own  transaction
    did so far. That's HeapTupleSatisfiesNow().

    Since they lock everything they access, they simply force the
    old (pre MVCC) behaviour - wait if something is  actually  in
    use  until the other transaction ends. No snapshots, no pain.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #