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 |
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 |