Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Oh, good point. I was thinking just about concurrent MERGEs. However,
> it is more complicated than that. By definitaion you can not see
> changes from other transactions while your statement is being run (even
> if you increment CommandCounter), so to be atomic, you would still see
> the row even though some other transaction had deleted it.
We would have to use the same semantics we use now for read-committed
UPDATE, that is look at the latest version of the row even though this
would not normally be visible to the transaction's snapshot.
In the case of a serializable transaction, no doubt we should fail if
any concurrent change actually happens.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
