On 2022-Jun-01, Justin Pryzby wrote:

> I prefer that way, with "See also" after the text that requires more
> information.  But the most important thing is to include the link at all.

But it's not a "see also".  It's a link to the primary source of
concurrency information for MERGE.  The text that follows is not talking
about concurrency, it just indicates that you can do something different
but related by using a different command.

Re-reading the modified paragraph, I propose "see X for a thorough
explanation on the behavior of MERGE under concurrency".  However, in
the proposed patch the link goes to Chapter 13 "Concurrency Control",
and the explanation that we intend to link to is hidden in subsection
13.2.1 "Read Committed Isolation level".  So it appears that we do not
have any explanation on how MERGE behaves in other isolation levels.
That can't be good ...

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"Cuando mañana llegue pelearemos segun lo que mañana exija" (Mowgli)
>From b41c2a1725af0ba3513219b8ea7eceb32e93f9e0 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera <alvhe...@alvh.no-ip.org>
Date: Wed, 18 May 2022 18:41:04 +0200
Subject: [PATCH v3] Link to MVCC docs in MERGE docs

---
 doc/src/sgml/mvcc.sgml      | 10 +++++-----
 doc/src/sgml/ref/merge.sgml |  2 ++
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 341fea524a..1d4d5a62f9 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -425,13 +425,13 @@ COMMIT;
    <para>
     <command>MERGE</command> allows the user to specify various
     combinations of <command>INSERT</command>, <command>UPDATE</command>
-    or <command>DELETE</command> subcommands. A <command>MERGE</command>
+    and <command>DELETE</command> subcommands. A <command>MERGE</command>
     command with both <command>INSERT</command> and <command>UPDATE</command>
     subcommands looks similar to <command>INSERT</command> with an
     <literal>ON CONFLICT DO UPDATE</literal> clause but does not
     guarantee that either <command>INSERT</command> or
     <command>UPDATE</command> will occur.
-    If MERGE attempts an <command>UPDATE</command> or
+    If <command>MERGE</command> attempts an <command>UPDATE</command> or
     <command>DELETE</command> and the row is concurrently updated but
     the join condition still passes for the current target and the
     current source tuple, then <command>MERGE</command> will behave
@@ -448,9 +448,9 @@ COMMIT;
     and execute the first one that succeeds.
     If <command>MERGE</command> attempts an <command>INSERT</command>
     and a unique index is present and a duplicate row is concurrently
-    inserted, then a uniqueness violation is raised.
-    <command>MERGE</command> does not attempt to avoid the
-    error by executing an <command>UPDATE</command>.
+    inserted, then a uniqueness violation error is raised;
+    <command>MERGE</command> does not attempt to avoid such
+    errors by evaluating <literal>MATCHED</literal> conditions.
    </para>
 
    <para>
diff --git a/doc/src/sgml/ref/merge.sgml b/doc/src/sgml/ref/merge.sgml
index f68aa09736..271076bfd5 100644
--- a/doc/src/sgml/ref/merge.sgml
+++ b/doc/src/sgml/ref/merge.sgml
@@ -539,6 +539,8 @@ MERGE <replaceable class="parameter">total_count</replaceable>
   </para>
 
   <para>
+   See <xref linkend="xact-read-committed"/> for a thorough explanation on the behavior of
+   <command>MERGE</command> under concurrency<!-- in READ COMMITTED isolation mode -->.
    You may also wish to consider using <command>INSERT ... ON CONFLICT</command>
    as an alternative statement which offers the ability to run an
    <command>UPDATE</command> if a concurrent <command>INSERT</command>
-- 
2.30.2

Reply via email to