bug report: some issues about pg_15_stable(8fa4a1ac61189efffb8b851ee77e1bc87360c445)

zwj <sxzwj@vip.qq.com>

From: zwj <sxzwj@vip.qq.com>
To: pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-02-18T01:37:39Z
Lists: pgsql-hackers

Attachments

Hello,

&nbsp;&nbsp; I found an issue while using the latest version of PG15 (8fa4a1ac61189efffb8b851ee77e1bc87360c445).

&nbsp;&nbsp; This question is about 'merge into'.


&nbsp;&nbsp; When two merge into statements are executed concurrently, I obtain the following process and results.&nbsp;
&nbsp;&nbsp; Firstly, the execution results of each Oracle are different, and secondly, I tried to understand its execution process and found that it was not very clear.


&nbsp;<merge into &amp; merge into&gt;


The first merge statement clearly updates the year field for ID 2 and 3, and then inserts the row for ID 4.
But when the second merge statement is executed, the year field of id 2 is actually updated based on the execution of the first merge statement, and then insert rows of id 3 and id 4.
I don't understand, I think if it is updated, it should be that both ID 2 and 3 have been updated.
I am currently unable to determine whether ID 4 should be updated or insert.



According to the results from Oracle, the second merge statement should have updated id 2 3 4.






<update &amp; merge into&gt;&nbsp;&nbsp;
I think the problem with the above scenario is due to the concurrent scenarios of update and merge, the behavior of PG and Oracle is consistent. The following figure:


(The results of Oracle and PG are consistent)
&nbsp; 

&nbsp;&nbsp; In my opinion, in the concurrent scenarios of mergeand merge, the behavior of pg seems inconsistent. Can you help me analyze and take a look, and help us use SQL with clearer semantics?
&nbsp; Looking forward to your reply.


Thanks
wenjiang_zhang

Commits

  1. Fix handling of self-modified tuples in MERGE.

  2. Sync PG_VERSION file in CREATE DATABASE.