Re: ON CONFLICT DO SELECT (take 3) - Mailing list pgsql-hackers

From Viktor Holmberg
Subject Re: ON CONFLICT DO SELECT (take 3)
Date
Msg-id 8b107b01-6e94-4919-a3bf-66af22c17899@Spark
Whole thread Raw
In response to Re: ON CONFLICT DO SELECT (take 3)  (Viktor Holmberg <v@viktorh.net>)
Responses Re: ON CONFLICT DO SELECT (take 3)
List pgsql-hackers
On 21 Jan 2026 at 21:06 +0100, Viktor Holmberg <v@viktorh.net>, wrote:
There are some white spaces in v19.
Sorry, what do you mean "white spaces”? Is it a problem?
it's time to squash the patchset into one, IMHO.
you can also begin to write the draft commit message, explain what this is all
about.
Yes, done.
ExecOnConflictSelect
if (lockStrength == LCS_NONE)
{
/* Evem if the tuple is deleted, it must still be physically present */
Assert(table_tuple_fetch_row_version(relation, conflictTid,
SnapshotAny, existing));
}
this is wrong, i think.
buildtype=release, the Assert macro will always be true,
the whole Assert may be optimized out,
and later code would have trouble using (TupleTableSlot *existing).
Yes, you’re right. Nice catch. Fixed.
updatable_views.sql: I did some ON CONFLICT DO SELECT permissions checks, and
other tests in it, please check attached.
Added

-----
I’ve updated all the comments you mentioned.
Thanks for the review Jian, I’m hoping we’ve caught all the issues now.
Please find v20 attached.
I went through all mentions of ON CONFLICT in the codebase to see there are no more forgotten comments/docs, and found 2 more places to update.
Attachment

pgsql-hackers by date:

Previous
From: Nikita Malakhov
Date:
Subject: Re: Unstable path in index regress test query
Next
From: Andres Freund
Date:
Subject: unnecessary executor overheads around seqscans