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

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

In response to

Browse pgsql-hackers by date

  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)