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 1pRtVK-0008LC-5E for pgsql-bugs@arkaria.postgresql.org; Tue, 14 Feb 2023 11:29:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pRtVI-0000C7-O6 for pgsql-bugs@arkaria.postgresql.org; Tue, 14 Feb 2023 11:29:44 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pRtVI-0000Bt-FM for pgsql-bugs@lists.postgresql.org; Tue, 14 Feb 2023 11:29:44 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pRtVB-0006mj-Hs for pgsql-bugs@lists.postgresql.org; Tue, 14 Feb 2023 11:29:44 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 86F965C00FD; Tue, 14 Feb 2023 06:29:35 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 14 Feb 2023 06:29:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=1676374175; x=1676460575; bh=CXlaSZEn9WOPG f44ofUYtqu1ROYmrOQ9o9CJs77VSqo=; b=ffqlJLeOFju6HCZjoHlHctibJAfjc y74zv77Vwm6jqPEpYFNE6gjUKEP2piMp7vBkdom5eZ0jm49bDSrckmZa7pxEF4Ln jJA3fYHlOsHHwFl2Z2jMjZ/6GYl4RcTqX5qv4zy5hQL15MUuukEddlphlozuo8nh pN0AblO76XgA4oPQw4qJvbxvt6Jpd+dGpq1ThlHw3Ld5hZ8NU88FrBNoCO2y8+9e CjN5dQgxGV9RBscMfm3gMQZer4hZpySHJhnC+cw05uI4LgeMfh87XUbFd7yBM5tB Vz7W6ZfqZBeuxDOnqqpRUK7uYZtVBJzuIQ7rO22Vek7BCxTv/9TBh2PWg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudeifedgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugfgjgesmhekre ertddtjeenucfhrhhomheptehlvhgrrhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgv segrlhhvhhdrnhhoqdhiphdrohhrgheqnecuggftrfgrthhtvghrnheptedvhfetueeuke efhfefudegfffhhefhvdelffelteekgeegfefhgfegkeejtddunecuffhomhgrihhnpegv nhhtvghrphhrihhsvggusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 14 Feb 2023 06:29:35 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 0B0969E; Tue, 14 Feb 2023 12:29:33 +0100 (CET) Date: Tue, 14 Feb 2023 12:29:33 +0100 From: Alvaro Herrera To: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17792: MERGE uses uninitialized pointer and crashes when target tuple is updated concurrently Message-ID: <20230214112933.cshqgnzpcioedizy@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ce5kdo4y4bapsfeo" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <17792-0f89452029662c36@postgresql.org> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --ce5kdo4y4bapsfeo Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On 2023-Feb-14, PG Bug reporting form wrote: > When executing the following queries with valgrind: > echo " > CREATE TABLE source (sid integer); > INSERT INTO source VALUES (1); > CREATE TABLE target (tid integer, tval integer); > INSERT INTO target VALUES (1, 1); > " | psql > At nodeModifyTable.c:2992 I see: > if (!TupIsNull(context->cpUpdateRetrySlot)) > > It looks like cpUpdateRetrySlot was not initialized on the context creation > in ExecModifyTable(), and ExecCrossPartitionUpdate(), where it could get a > value, just not called for this case. Hmm, yeah: because this is not a partitioned table, we are definitely not expecting that cpUpdateRetrySlot will be set. Can you still reproduce the problem with the attached patch? I'm not sure that the location of the initialization is best. My first impulse was to add it in line 3618, with the "Set global context" lines; but then I think it's possible for one tuple of a partition to be routed correctly and a later one that is concurrently updated suffer from an improper value in cpUpdateRetrySlot. Also, the comment is not great ... -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ --ce5kdo4y4bapsfeo Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="merge-uninit.patch" diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c index 1ac65172e4..2a0e002dc9 100644 --- a/src/backend/executor/nodeModifyTable.c +++ b/src/backend/executor/nodeModifyTable.c @@ -3630,6 +3630,9 @@ ExecModifyTable(PlanState *pstate) */ ResetPerTupleExprContext(estate); + /* Decisions are made based on whether this is NULL for each tuple */ + context.cpUpdateRetrySlot = NULL; + /* * Reset per-tuple memory context used for processing on conflict and * returning clauses, to free any expression evaluation storage --ce5kdo4y4bapsfeo--