Re: MERGE vs REPLACE - Mailing list pgsql-hackers

From Tom Lane
Subject Re: MERGE vs REPLACE
Date
Msg-id 6410.1132328075@sss.pgh.pa.us
Whole thread Raw
In response to Re: MERGE vs REPLACE  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: MERGE vs REPLACE  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: someone working to add merge?
Next
From: Tom Lane
Date:
Subject: Re: Improving count(*)