On Wed, Jun 1, 2022, at 5:28 PM, Alvaro Herrera wrote:
> 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 ...

OK, here's slightly updated wording for this, after reading the MVCC docs 
again. I didn't change the link to point specifically to read-committed, but I 
worded the reference to suggest that the referenced explanation is within each 
isolation level's subsection. In reality, there's not much to say about each 
specific command in REPEATABLE READ and SERIALIZABLE, but in the former I added 
MERGE to the list of commands.

I checked the pages for UPDATE and DELETE, to see if they had any explanation 
of concurrency, to use that as precedent. I couldn't find anything.
From 582f8b932cc515485bfdb84479f0600f91bbf9a7 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 v4] Link to MVCC docs in MERGE docs

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

diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 341fea524a..2f8d2b17ef 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>
@@ -516,8 +516,9 @@ COMMIT;
    </para>
 
    <para>
-    <command>UPDATE</command>, <command>DELETE</command>, <command>SELECT
-    FOR UPDATE</command>, and <command>SELECT FOR SHARE</command> commands
+    <command>UPDATE</command>, <command>DELETE</command>,
+    <command>MERGE</command>, <command>SELECT FOR UPDATE</command>,
+    and <command>SELECT FOR SHARE</command> commands
     behave the same as <command>SELECT</command>
     in terms of searching for target rows: they will only find target rows
     that were committed as of the transaction start time.  However, such a
diff --git a/doc/src/sgml/ref/merge.sgml b/doc/src/sgml/ref/merge.sgml
index f68aa09736..f0745d01c7 100644
--- a/doc/src/sgml/ref/merge.sgml
+++ b/doc/src/sgml/ref/merge.sgml
@@ -539,6 +539,10 @@ MERGE <replaceable class="parameter">total_count</replaceable>
   </para>
 
   <para>
+   When <command>MERGE</command> is run concurrently with other commands
+   that modify the target table, the usual transaction isolation rules
+   apply; see <xref linkend="transaction-iso"/> for an explanation
+   on the behavior at each isolation level.
    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