Re: SSI: ON CONFLICT DO SELECT takes no predicate lock on the returned row

> On 19 Aug 2026, at 22:32, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
>
> <v2-0001-Take-SIREAD-lock-on-rows-read-by-ON-CONFLICT-DO-S.patch>

Hi Zsolt and Andres,

Yes, I think this is another manifestation of the same underlying issue.
My June patch happened to cover DO SELECT too, because it put the SIREAD
lock in the common arbiter probe, although the email only mentioned DO
NOTHING and DO UPDATE with a false WHERE clause.

However, I agree that the June fix has the race you pointed out. A
writer can pass its conflict-in check between the dirty arbiter probe
and PredicateLockTID(). The MVCC fetch in v2 handles both directions:
it either installs the SIREAD lock before a future writer, or detects a
writer that has already modified the tuple. This looks like the right
approach to me.

The commit message explains why the fetch must precede FOR KEY SHARE,
but the test uses FOR UPDATE. Could we test FOR KEY SHARE with a
non-key UPDATE instead? That would distinguish this ordering from
taking the SIREAD lock after the tuple lock.

It would also be useful to cover DO SELECT WHERE false. The conflicting
row is not returned in that case, but it still determined the outcome of
the INSERT and was examined by the WHERE clause.

After that, I think we should adapt the same approach to the DO NOTHING
and filtered DO UPDATE cases in the older branches.

Thank you!

Best regards, Andrey Borodin.