bug report: some issues about pg_15_stable(8fa4a1ac61189efffb8b851ee77e1bc87360c445) - Mailing list pgsql-hackers
Hello,
I found an issue while using the latest version of PG15 (8fa4a1ac61189efffb8b851ee77e1bc87360c445).
I found an issue while using the latest version of PG15 (8fa4a1ac61189efffb8b851ee77e1bc87360c445).
This question is about 'merge into'.
When two merge into statements are executed concurrently, I obtain the following process and results.
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.
<merge into & merge into>
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 & merge into>
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）
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?
Looking forward to your reply.
Thanks
wenjiang_zhang
Attachment
pgsql-hackers by date: