Re: Inconsistent update in the MERGE command
Yugo Nagata <nagata@sraoss.co.jp>
From: Yugo Nagata <nagata@sraoss.co.jp>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Dmitry <dsy.075@yandex.ru>, pgsql-hackers@lists.postgresql.org
Date: 2025-08-28T14:10:01Z
Lists: pgsql-hackers
Attachments
On Wed, 27 Aug 2025 14:44:55 +0100 Dean Rasheed <dean.a.rasheed@gmail.com> wrote: > On Sun, 24 Aug 2025 at 18:34, Yugo Nagata <nagata@sraoss.co.jp> wrote: > > > > I confirmed this issue by executing the following query concurrently > > in three transactions. (With only two transactions, the issue does not occur.) > > Yes, I think 3 transactions are required to reproduce this (2 separate > concurrent updates). > > > I don't completely understand how this race condition occurs, > > but I believe the bug is due to the misuse of TM_FailureData > > returned by table_tuple_lock in ExecMergeMatched(). > > > > Currently, TM_FailureData.ctid is used as a reference to the > > latest version of oldtuple, but this is not always correct. > > Instead, the tupleid passed to table_tuple_lock should be used. > > > > I've attached a patch to fix this. > > Thanks. That makes sense. > > I think we also should update the isolation tests to test this. > Attached is an update to the merge-match-recheck isolation test, doing > so. As you found, it doesn't always seem to fail with the unpatched > code (though I didn't look to see why), but with your patch, it always > passes. Thank you for your suggestion and the test patch. The test looks good to me, so I’ve attached an updated patch including it. Regards, Yugo Nagata -- Yugo Nagata <nagata@sraoss.co.jp>
Commits
-
Fix concurrent update issue with MERGE.
- f871fbae9d00 15.15 landed
- 21a61b87f47b 16.11 landed
- 6195afbe536a 17.7 landed
- c70b6db34ffe 18.0 landed
- 6ede13d1b5f5 19 (unreleased) landed