| From: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
|---|---|
| To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Nathan Bossart <nathandbossart(at)gmail(dot)com>, 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-09-10 07:18:49 |
| Message-ID: | CAN4CZFORKTdTE12ZfLjeL27es3Rps18ErQEO8vE1W8AFPOC0-g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > However, that fix seems to have the same kind of layering
> > violation that Andres complained about for the first version of the
> > patch on this thread -- predicate locking should be in heapam code,
> > not in execIndexing.c.
>
> It's not just the layering violation, that solution also has a leftover issue, similarly to my first patch in this thread. When I looked at this my initial conclusion was that we can't fix the two at the same place without layering violations / remaining issues, so my idea was to apply the same fix as I did for SELECT to those paths, but I'll take another look at it.
And I was wrong, this approach is simple and works for all reported
cases, I attached v4 which uses this approach.
| Attachment | Content-Type | Size |
|---|---|---|
| v4-0001-Fix-missing-SIREAD-lock-on-the-row-found-by-ON-CO.patch | application/octet-stream | 17.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-09-10 07:23:40 | Re: Review items for EXCEPT TABLE publication |
| Previous Message | Chao Li | 2026-09-10 07:17:17 | Re: Review items for EXCEPT TABLE publication |