| From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
|---|---|
| To: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
| Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(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 08:45:31 |
| Message-ID: | 6D78D76C-A473-4CBF-BD5E-9C8DACF63803@yandex-team.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Zsolt,
On 10 Sep 2026, Zsolt Parragi wrote:
> this approach is simple and works for all reported cases
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.
I checked the DO NOTHING and filtered DO UPDATE cases on REL_14_STABLE
too, using the same code change without the injection point. All three
permutations allow both transactions to commit without the fix, and
produce the expected serialization failures with it.
Thank you!
Best regards, Andrey Borodin.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2026-09-10 08:58:04 | Re: Revert RI fast-path batching from REL_19_STABLE |
| Previous Message | Rahila Syed | 2026-09-10 08:39:20 | Removal of ResourceOwnerReleaseAllOfKind function |