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