pgsql: Fix concurrent update issue with MERGE.

Fix concurrent update issue with MERGE.

When executing a MERGE UPDATE action, if there is more than one
concurrent update of the target row, the lock-and-retry code would
sometimes incorrectly identify the latest version of the target tuple,
leading to incorrect results.

This was caused by using the ctid field from the TM_FailureData
returned by table_tuple_lock() in a case where the result was TM_Ok,
which is unsafe because the TM_FailureData struct is not guaranteed to
be fully populated in that case. Instead, it should use the tupleid
passed to (and updated by) table_tuple_lock().

To reduce the chances of similar errors in the future, improve the
commentary for table_tuple_lock() and TM_FailureData to make it
clearer that table_tuple_lock() updates the tid passed to it, and most
fields of TM_FailureData should not be relied on in non-failure cases.
An exception to this is the "traversed" field, which is set in both
success and failure cases.

Reported-by: Dmitry <dsy(dot)075(at)yandex(dot)ru>
Author: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
Reviewed-by: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Reviewed-by: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 15

Branch
------
REL_18_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/c70b6db34ffeab48beef1fb4ce61bcad3772b8dd

Modified Files
--------------
src/backend/executor/nodeModifyTable.c | 9 +-
src/include/access/tableam.h | 15 ++-
.../isolation/expected/merge-match-recheck.out | 145 +++++++++++++++++++++
src/test/isolation/specs/merge-match-recheck.spec | 18 +++
4 files changed, 179 insertions(+), 8 deletions(-)