Re: MERGE behavior with REPEATABLE READ isolation level - Mailing list pgsql-hackers

From Tender Wang
Subject Re: MERGE behavior with REPEATABLE READ isolation level
Date
Msg-id CAHewXNmtg=-WRczRUmd0tyNaP57WYOg74=O2pMssq9hWS3YoOw@mail.gmail.com
Whole thread Raw
In response to Re: MERGE behavior with REPEATABLE READ isolation level  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: MERGE behavior with REPEATABLE READ isolation level
Re: MERGE behavior with REPEATABLE READ isolation level
List pgsql-hackers
Hi Alexander,

Alexander Korotkov <aekorotkov@gmail.com> 于2026年2月15日周日 09:23写道:
> Oh, sorry I missed the begin statement for s1.  The complete case should look like this.
>
> s1# create table test (id int primary key, val int);
> s1# insert into test values (1,0);
>
>   s2# begin;
>   s2# update test set val = val + 100;
>
> s1# begin isolation level repeatable read;
> s1# MERGE INTO test t USING (VALUES (1, 100)) AS s (id, inc)
>       ON t.id = s.id
>     WHEN MATCHED THEN
>       UPDATE SET val = t.val + s.inc
>     WHEN NOT MATCHED THEN
>       INSERT (id, val) VALUES (s.id, s.inc);
> (waiting ...)
>
>   s2# commit;
>
> s1# MERGE 1
> s1# select * from test;
>  id | val
> ----+-----
>   1 | 200
> (1 row)
>

I tried "update test set val = val + 100;" but the SQL reported a
"could not serialize access due to concurrent update" error.
It seems that the MERGE command should behave identically to UPDATE
when performing a match action.

I wrote a fix patch and attached it, and added your test case, too.


--
Thanks,
Tender Wang

Attachment

pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Re: DOCS - pg_walsummary typo?
Next
From: Chao Li
Date:
Subject: Re: DOCS - pg_waldump synopsis sgml markup