| From: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
| Subject: | Re: SSI: ON CONFLICT DO SELECT takes no predicate lock on the returned row |
| Date: | 2026-08-19 19:32:48 |
| Message-ID: | CAN4CZFM2EsCEWZWsQdRDTOkvEE-zxNno-vu1oMTT86GyFgKptA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Good catch.
Look like we also had a real-life serialization issue, this was
already mentioned and fixed differently by Andrey in another thread
[1]. That thread also has a different serialization-related patch I
was reviewing at the same time, and I didn't notice that Andrey sent
another email that day.
His patch also handles a similar issue in DO UPDATE / DO NOTHING which
my patch didn't address.
> I don't think this is quite right though. The details of how heapam uses SI
> locks is heapam specific and should live in the heapam code. I also think you
> actually need to acquire the predicate lock before ExecOnConflictLockRow()?
You are right, and after looking at Andrey's patch I think that it
also might have a similar but smaller race window, so I'll still
attach this v2 as it tries a different direction. This v2 still only
addresses the DO SELECT part.
Please also take a look at the patches in the other thread, both for
this issue and the other more corner-case issue we were discussing
there.
[1] https://www.postgresql.org/message-id/787936C5-4155-4CF9-939D-39DC0EC1C892@yandex-team.ru
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Take-SIREAD-lock-on-rows-read-by-ON-CONFLICT-DO-S.patch | application/octet-stream | 7.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Lakhin | 2026-08-19 20:00:01 | Test tidscan,sql is not immune to autovacuum in v14 |
| Previous Message | Bruce Momjian | 2026-08-19 19:25:02 | Re: hashjoins vs. Bloom filters (yet again) |