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

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Cc: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, pgsql-hackers mailing list <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Nathan Bossart <nathandbossart(at)gmail(dot)com>
Subject: Re: SSI: ON CONFLICT DO SELECT takes no predicate lock on the returned row
Date: 2026-09-10 10:24:37
Message-ID: CAEZATCX+tbrJPcqSLBhQ8TRxvKJcwrUTrqwEOW3Y8DJfERuP5A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 10 Sept 2026 at 09:45, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>
> On 10 Sep 2026, Zsolt Parragi wrote:
> > this approach is simple and works for all reported cases
>

Thanks for the update. The new patch looks good.

> I reviewed v4 and it looks correct to me. I also replaced the MVCC fetch
> with just PredicateLockTID(): the ordinary isolation test still passed,
> but all three probe-window permutations allowed both transactions to
> commit. The new test catches the race in my June approach.
>

It looks correct to me too. It's a nice touch using injection points
to confirm that there's no longer an issue with the window between
probe and re-fetch.

Nitpicking, I'd say that it's better to name the steps in the tests
things like "ioc_nothing1" and "ioc_update1_where", so that they're
more distinct from steps like "update2", which is just a plain update.

Other than that, I'd say that it's ready to commit, but I'll take
another couple of days to think it over more thoroughly, before
pushing it (probably at the weekend).

Regards,
Dean

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2026-09-10 10:25:58 Re: Review items for EXCEPT TABLE publication
Previous Message Etsuro Fujita 2026-09-10 09:24:55 Re: postgres_fdw: transaction mode inheritance corner cases