On Sun, Oct 24, 2010 at 10:43 AM, Robert Haas <robertmh...@gmail.com> wrote: > But let's back up and talk about MVCC for a minute. Suppose we have > three source tuples, (1), (2), and (3); and the target table contains > tuples (1) and (2), of which only (1) is visible to our MVCC snapshot; > suppose also an equijoin. Clearly, source tuple (1) should fire the > MATCHED rule and source tuple (3) should fire the NOT MATCHED rule, > but what in the world should source tuple (2) do? AFAICS, the only > sensible behavior is to throw a serialization error, because no matter > what you do the results won't be equivalent to a serial execution of > the transaction that committed target tuple (2) and the transaction > that contains the MERGE.
So the behaviour we get with UPDATE in this situation is that we update (2) so I would expect this to execute the MATCHED rule. The key distinction is that since we're not returning the data to the user the user sees we want to update the most recent version and it's "almost" as if we ran "after" all the other transactions. It's not really serializable and I think in serializable mode we throw a serialization failure instead but in most usage patterns it's precisely what the user wants. Here "bbb" contained two records when we began with values "1" and "2" but the "2" was inserted in a transaction which hadn't committed yet. It commited after the update. postgres=> begin; BEGIN postgres=> select * from bbb; i --- 1 (1 row) postgres=> update bbb set i = i+1; UPDATE 2 postgres=> commit; COMMIT postgres=> select * from bbb; i --- 2 3 (2 rows) -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
