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) #
