Fix handling of self-modified tuples in MERGE.
authorDean Rasheed <dean.a.rasheed@gmail.com>
Thu, 7 Mar 2024 09:57:02 +0000 (09:57 +0000)
committerDean Rasheed <dean.a.rasheed@gmail.com>
Thu, 7 Mar 2024 09:57:02 +0000 (09:57 +0000)
commit29ef1dd19b4f3eb54569b2eece4a8a65034a2216
tree6176547a0c7e14a45473fb182ff31c948fb97130
parente444ebcb85c0b55b1ccf7bcb785ad2708090a2a2
Fix handling of self-modified tuples in MERGE.

When an UPDATE or DELETE action in MERGE returns TM_SelfModified,
there are 2 possible causes:

1). The target tuple was already updated or deleted by the current
    command. This can happen if the target row joins to more than one
    source row, and the SQL standard explicitly says that this must be
    an error.

2). The target tuple was already updated or deleted by a later command
    in the current transaction. This can happen if the tuple is
    modified by a BEFORE trigger or a volatile function used in the
    query, and should be an error for the same reason that it is in a
    plain UPDATE or DELETE command.

In MERGE's primary error handling block, it failed to check for (2),
causing it to return a misleading error message in such cases.

In the secondary error handling block, following a concurrent update
from another session, it failed to check for (1), causing it to
silently ignore target rows joined to more than one source row,
instead of reporting an error.

Fix this, and add tests for both of these cases.

Per report from Wenjiang Zhang. Back-patch to v15, where MERGE was
introduced.

Discussion: https://postgr.es/m/tencent_41DE0FF443FE14B94A5898D373792109E408%40qq.com
src/backend/executor/nodeModifyTable.c
src/test/isolation/expected/merge-update.out
src/test/isolation/specs/merge-update.spec
src/test/regress/expected/triggers.out
src/test/regress/sql/triggers.sql