Re: Inconsistent update in the MERGE command

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
Cc: Dmitry <dsy(dot)075(at)yandex(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Inconsistent update in the MERGE command
Date: 2025-08-27 13:44:55
Message-ID: CAEZATCU2jAB_m4TR60Sin=L9TfKZ2fyAqZ3ufOOAqx=6aqm2Dw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 24 Aug 2025 at 18:34, Yugo Nagata <nagata(at)sraoss(dot)co(dot)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.

Regards,
Dean

Attachment Content-Type Size
isolation-tests.patch text/x-patch 10.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2025-08-27 13:57:13 Re: Per backend relation statistics tracking
Previous Message Bertrand Drouvot 2025-08-27 13:43:49 Re: Report bytes and transactions actually sent downtream