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 1nVWdX-0006ri-W4 for pgsql-hackers@arkaria.postgresql.org; Sat, 19 Mar 2022 10:48:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nVWdW-0002bX-F0 for pgsql-hackers@arkaria.postgresql.org; Sat, 19 Mar 2022 10:48:42 +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 1nVWdW-0002bO-5q for pgsql-hackers@lists.postgresql.org; Sat, 19 Mar 2022 10:48:42 +0000 Received: from new4-smtp.messagingengine.com ([66.111.4.230]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nVWdP-00056J-8Z for pgsql-hackers@lists.postgresql.org; Sat, 19 Mar 2022 10:48:40 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 0E48458016A; Sat, 19 Mar 2022 06:48:34 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 19 Mar 2022 06:48:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date: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= fm3; bh=b71ywcWhcnSOpnJZGDK+fc14d96d754Ql7VxtXZnDNA=; b=mwnqJS+O HjpMl36MCutQcgl6d7VdB2me0PeEZ1WHnLeK3jkGjKx/aIPW9YzQHYJBwN9TcMiO xXwZhRYtqfB1s5Ncbpx0GbSB4D/dVpcYejMnG00CDqTtZG6oHzH7xuWOC0l0KXmf WzsyqsyKNNTvsikDE4KgIZ64o7oFAtfdijmLr8yTKC2qDLix2LKixT5SyGWH0HZv b06dCl7Uam++5ZAzmbHkjzBpcjaM9YESVKu0z3R+72JRSfinbhQWdHkF1ixpzKnT AC5mr48NMIN8RCDrV5azgREJ4I5ua1C6sJPFGbKazP8y4smtCWIjSDXHEpQCiYsT 1e+XFNRcRWCYfQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudefkedgvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne govfgvgihtqfhnlhihqddqufhprghmsghothdqkgegvddvqdejuddqsghishculdeftddt mdenucfjughrpeffhffvuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvh grrhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhr gheqnecuggftrfgrthhtvghrnhepudejveejffejveduudetvdekieeuiedtvdeileefke evjedufeeguedvjefhueelnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtgho mhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlh hvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 19 Mar 2022 06:48:31 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 1A1DE2A0B5A; Sat, 19 Mar 2022 07:48:35 -0300 (-03) Date: Sat, 19 Mar 2022 11:48:35 +0100 From: Alvaro Herrera To: Simon Riggs Cc: Andres Freund , Pg Hackers , Tomas Vondra , Zhihong Yu , Daniel Westermann , Amit Langote , Justin Pryzby , Japin Li , Erik Rijkers , Jaime Casanova Subject: Re: support for MERGE Message-ID: <202203191048.fejpvy4fld7d@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022-Mar-10, Simon Riggs wrote: > Duplicate rows should produce a uniqueness violation error in one of > the transactions, assuming there is a constraint to define the > conflict. Without such a constraint there is no conflict. > > Concurrent inserts are checked by merge-insert-update.spec, which > correctly raises an ERROR in this case, as documented. Agreed -- I think this is reasonable. > Various cases were not tested in the patch - additional patch > attached, but nothing surprising there. Thank you, I've included this in all versions of the patch since you sent it. > ExecInsert() does not return from such an ERROR, so the code fragment > appears correct to me. I think trying to deal with it in a different way (namely: suspend processing the inserting WHERE NOT MATCHED clause and switch to processing the row using WHERE MATCHED clauses) would require us use speculative tokens, similar to the way INSERT ON CONFLICT does. I'm not sure we want to go there, but it seems okay to leave that for a later patch. Moreover, there would be no compatibility hit from doing so. -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/ "La persona que no quería pecar / estaba obligada a sentarse en duras y empinadas sillas / desprovistas, por cierto de blandos atenuantes" (Patricio Vogel)