Re: ON CONFLICT DO SELECT (take 3)

From: jian he <jian(dot)universality(at)gmail(dot)com>
To: Viktor Holmberg <v(at)viktorh(dot)net>
Cc: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, 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-02-04 10:22:16
Message-ID: CACJufxGdo1aycnkPPW0H_GgzkV2wxdCZZy3UncQ28pWQn=J7xg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

hi.

v22 looks good to me.
I have marked this as "Ready for Committer".

+ <para>
+ <command>INSERT</command> with an <literal>ON CONFLICT DO
+ SELECT</literal> clause behaves similarly to <literal>ON CONFLICT DO
+ UPDATE</literal>. In Read Committed mode, if a conflict originates
+ in another transaction whose effects are not yet visible to the
+ <command>INSERT</command>, the <literal>SELECT</literal> clause will
+ return that row, even though possibly <emphasis>no</emphasis> version
+ of that row is conventionally visible to the command.
+ </para>
+
I think I understand the above paragraph.

however the preceding paragraph (doc/src/sgml/mvcc.sgml), we have:
"""
In Read Committed mode, each row proposed for insertion
will either insert or update. Unless there are unrelated errors, one of
those two outcomes is guaranteed.
"""
Maybe we can write something similar for INSERT ON CONFLICT?

--
jian
https://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2026-02-04 10:22:22 Re: Row pattern recognition
Previous Message David Geier 2026-02-04 10:09:32 Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?