>
> > Oh - well - vacuum shouldn't touch relations where
> > deferred triggers are outstanding. Might require some
> > special lock entry - Vadim?
>
> All modified data will be in this same still open transaction.
> Therefore no relevant data can be removed by vacuum anyway.
I expect this, but I really need to be sure that not even the
location of the tuple in the heap will change. I need to find
the tuples at the time the deferred triggers must be executed
via heap_fetch() by their CTID!
>
> It is my understanding, that the RI check is performed on the newest
> available (committed) data (+ modified data from my own tx).
> E.g. a primary key that has been removed by another transaction after
> my begin work will lead to an RI violation if referenced as foreign key.
Absolutely right. The function that will fire the deferred
triggers must switch to READ COMMITTED isolevel while doing
so.
What I'm not sure about is which snapshot to use to get the
OLD tuples (outdated in this transaction by a previous
command). Vadim?
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) #
