Re: ON CONFLICT DO SELECT (take 3)

From: Viktor Holmberg <v(at)viktorh(dot)net>
To: jian he <jian(dot)universality(at)gmail(dot)com>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Marko Tiikkaja <marko(at)joh(dot)to>, Andreas Karlsson <andreas(at)proxel(dot)se>
Subject: Re: ON CONFLICT DO SELECT (take 3)
Date: 2026-01-23 20:10:00
Message-ID: 8b107b01-6e94-4919-a3bf-66af22c17899@Spark
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 21 Jan 2026 at 21:06 +0100, Viktor Holmberg <v(at)viktorh(dot)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 Content-Type Size
v21-0001-Add-ON-CONFLICT-DO-SELECT-FOR-SHARE-UPDATE.patch application/octet-stream 152.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2026-01-23 20:16:02 unnecessary executor overheads around seqscans
Previous Message Nikita Malakhov 2026-01-23 18:17:38 Re: Unstable path in index regress test query