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

From jian he
Subject Re: ON CONFLICT DO SELECT (take 3)
Date
Msg-id CACJufxGdo1aycnkPPW0H_GgzkV2wxdCZZy3UncQ28pWQn=J7xg@mail.gmail.com
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
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



pgsql-hackers by date:

Previous
From: David Geier
Date:
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Next
From: Tatsuo Ishii
Date:
Subject: Re: Row pattern recognition