> Looking back at our discussion around 24-Oct, I recall that I was
> leaning to the idea that the correct interpretation of the spec's
> "triggered data change" rule is that it prohibits scenarios that are
> impossible anyway under MVCC, because of the MVCC tuple visibility
> rules. Therefore we don't need any explicit test for triggered data
> change. But I didn't hear anyone else supporting or disproving
> that idea.
>
> The code as-is is certainly wrong, since it prohibits multiple changes
> within a transaction, not within a statement as the spec says.
>
> Right at the moment I'd favor ripping the code out entirely ... but
> it'd be good to hear some support for that approach. Comments anyone?
If I read the code correctly, the "triggered data change" check is only
performed for keys, that have xmin == GetCurrentTransactionId().
Those are tuples that have already been modified by current session.
Since nobody else can touch those (since they are locked), I think the
check is not needed.
(Delete lines 2176 - 2200 and 2211 - 2229, that was your intent, Tom ?)
I think this would be correct.
I somehow wonder on the contrary why a check would not be necessary
for the exact opposite case, where oldtup->t_data->t_xmin !=
GetCurrentTransactionId(), since such a key might have been changed
from another session. (Or does a referenced key always get a lock ?)
Andreas
