Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nwQGr-0002cG-Td for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Jun 2022 15:28:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nwQGp-0004fE-Ef for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Jun 2022 15:28:27 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nwQGo-0004f5-Dt for pgsql-hackers@lists.postgresql.org; Wed, 01 Jun 2022 15:28:27 +0000 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nwQGh-00039n-QA for pgsql-hackers@lists.postgresql.org; Wed, 01 Jun 2022 15:28:25 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 056FB3200BAA; Wed, 1 Jun 2022 11:28:15 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 01 Jun 2022 11:28:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1654097295; x=1654183695; bh=i dMyWYPjH4XVK81apsK5Qjkq/zh42N5zT6juFljszQQ=; b=q0bjj9EgF0TTiXFtk s3WvPHgAsKfLqvkF7MFzSfYXdPh5YsaqEoIw/AYfHOc71T2CuOaaM6YEDupsi0IJ W9sNJCqS7/wIQ64sI5V0irCmGypmj7rpgtDNjyxK1QGHfuHxWJUV2yNALPKZb/Y5 JVqQUXgvpmuCad05syz6fC3QfCt3mrsVR72R5AFM95vfq8qrefnwCG7FugHY+AoM 8lrFxdfBSB5jl1nL/xnjGmMVlxTDUuupj307RLQ0QKrwx2Tz8PiUid7SYqdeucMu vvzqoEi3slWM/5YKz+K88q/cGeIoz22S6gyU6uE2KLoryOPMXTBhrCdCSlbCvpNc VqyjA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrledtgdekkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfggtggugfgjsehmkeerredttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpeduleekkefgtddttedtkefguddvieffleetgeejiefhteeh keevfeettdduvdfhueenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 1 Jun 2022 11:28:14 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 4A2E82A0843; Wed, 1 Jun 2022 17:28:10 +0200 (CEST) Date: Wed, 1 Jun 2022 17:28:10 +0200 From: Alvaro Herrera To: Justin Pryzby Cc: Peter Eisentraut , Amit Langote , Japin Li , Zhihong Yu , Simon Riggs , pgsql-hackers@lists.postgresql.org, Tomas Vondra , Daniel Westermann , Erik Rijkers , Jaime Casanova , Andres Freund Subject: Re: support for MERGE Message-ID: <202206011528.j2i6c64v7yqs@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bsuz7mbwvsdnim3l" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220601110317.GC29853@telsasoft.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --bsuz7mbwvsdnim3l Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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) --bsuz7mbwvsdnim3l Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v3-0001-Link-to-MVCC-docs-in-MERGE-docs.patch" From b41c2a1725af0ba3513219b8ea7eceb32e93f9e0 Mon Sep 17 00:00:00 2001 From: Alvaro Herrera 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; MERGE allows the user to specify various combinations of INSERT, UPDATE - or DELETE subcommands. A MERGE + and DELETE subcommands. A MERGE command with both INSERT and UPDATE subcommands looks similar to INSERT with an ON CONFLICT DO UPDATE clause but does not guarantee that either INSERT or UPDATE will occur. - If MERGE attempts an UPDATE or + If MERGE attempts an UPDATE or DELETE and the row is concurrently updated but the join condition still passes for the current target and the current source tuple, then MERGE will behave @@ -448,9 +448,9 @@ COMMIT; and execute the first one that succeeds. If MERGE attempts an INSERT and a unique index is present and a duplicate row is concurrently - inserted, then a uniqueness violation is raised. - MERGE does not attempt to avoid the - error by executing an UPDATE. + inserted, then a uniqueness violation error is raised; + MERGE does not attempt to avoid such + errors by evaluating MATCHED conditions. 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 total_count + See for a thorough explanation on the behavior of + MERGE under concurrency. You may also wish to consider using INSERT ... ON CONFLICT as an alternative statement which offers the ability to run an UPDATE if a concurrent INSERT -- 2.30.2 --bsuz7mbwvsdnim3l--