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-09-04 12:50:41 |
Message-ID: | CAEZATCWwtWLd_rhO4b=hfaKHOCbPkVr-XaxwsYL-ZBppO3=D1w@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 28 Aug 2025 at 15:10, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> wrote:
>
> Thank you for your suggestion and the test patch. The test looks good
> to me, so I’ve attached an updated patch including it.
Thanks, that mostly looks good to me.
There's one other place in ExecMergeMatched() that's using
TM_FailureData.ctid when it shouldn't, and that's this check:
if (ItemPointerIndicatesMovedPartitions(&context->tmfd.ctid))
ereport(ERROR,
(errcode(ERRCODE_T_R_SERIALIZATION_FAILURE),
errmsg("tuple to be merged was already moved to
another partition due to concurrent update")));
I've updated that to use tupleid in the attached v3 patch, and added a
couple more isolation tests. In practice, however, I don't think that
error can ever happen because this check follows table_tuple_lock()
which has a similar test which will always error out first. I was
tempted to simply remove this check from ExecMergeMatched(), but I
think perhaps it's worth keeping just in case.
Also, I thought that it's worth updating the comments for
table_tuple_lock() and TM_FailureData to make it clearer that it
updates its tid argument, and which fields of TM_FailureData can be
relied upon in the different cases.
Regards,
Dean
Attachment | Content-Type | Size |
---|---|---|
v3-0001-Fix-concurrent-update-issue-with-MERGE.patch | text/x-patch | 18.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Vlada Pogozhelskaya | 2025-09-04 13:08:05 | [PATCH] Referenced generic plan mode |
Previous Message | Dilip Kumar | 2025-09-04 12:02:27 | Re: Potential problem in commit f777d773878 and 4f7f7b03758 |