From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <Inoue(at)tpf(dot)co(dot)jp> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Triggered Data Change check |
Date: | 2001-11-12 10:18:43 |
Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA41EB403@m0114.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | David Eduardo Gomez Noguera | 2001-11-12 13:10:45 | timestamp |
Previous Message | pgsql-hackers | 2001-11-12 09:32:28 | replicate "sequence" using rserv |