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 1l1WLb-0007GG-2D for pgsql-hackers@arkaria.postgresql.org; Mon, 18 Jan 2021 15:21:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1l1WLZ-0007jZ-VC for pgsql-hackers@arkaria.postgresql.org; Mon, 18 Jan 2021 15:21:37 +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 1l1WLZ-0007jS-Og for pgsql-hackers@lists.postgresql.org; Mon, 18 Jan 2021 15:21:37 +0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l1WLX-0003An-S1 for pgsql-hackers@lists.postgresql.org; Mon, 18 Jan 2021 15:21:37 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id A486C5C00CD; Mon, 18 Jan 2021 10:21:34 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 18 Jan 2021 10:21:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=oTI5Shp8tZ4uXGwFH6Rn1ToYEk9wQoS+si7t1o5f30M=; b=Y5DfTXfC Co4xWn5mo1VHL851nkdc2sW5EdtTQA1tTouChfA+pnXmKx3WltvsVjkgB82chbjN IU6Ngc5Cp1KpZa4Byr4s0ye4AUwhVz4lgu4EgowM+VO6O6170OiMt2EE7KQ/ehUm rIUzq23qB8ob3KvvMMtXemmxF2e/br2x+KU+ikGZP3/UCMWHgVY/uQ5g6hGUkMXD weOVcK0CEGEdstRbSN7aWU63pXT/2h7+NBB9Uz/a5N8oKEPQei9kRqGz4DnZACZw Ri2Q5zhZwHriQXaeddZ+f7iYvvDN6Looi66cXMpKzjA5FCG13SPgMNTADWlBlBD3 or2r/8pANFTs4Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrtdekgdejiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkgggtugfgjggfsehtkeertddtredunecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpeeufffhjeeiueeuffegvddukeegledtveeivdeiueefieei vefgteehueefteehvdenucfkphepudeltddrleehrdduledrudejjeenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvgesrghl vhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.19.177]) by mail.messagingengine.com (Postfix) with ESMTPA id BDED224006A; Mon, 18 Jan 2021 10:21:33 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 83A732A0928; Mon, 18 Jan 2021 12:21:31 -0300 (-03) Date: Mon, 18 Jan 2021 12:21:31 -0300 From: Alvaro Herrera To: Pg Hackers Cc: Jaime Casanova Subject: Re: support for MERGE Message-ID: <20210118152131.GA17413@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210108192200.GA25633@alvherre.pgsql> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Jaime Casanova just reported that this patch causes a crash on the regression database with this query: MERGE INTO public.pagg_tab_ml_p3 as target_0 USING public.prt2_l_p3_p2 as ref_0 ON target_0.a = ref_0.a WHEN MATCHED AND cast(null as tid) <= cast(null as tid) THEN DELETE; The reason is down to adjust_partition_tlist() not being willing to deal with empty tlists. So this is the most direct fix: diff --git a/src/backend/executor/execPartition.c b/src/backend/executor/execPartition.c index 1fa4d84c42..d6b478ec33 100644 --- a/src/backend/executor/execPartition.c +++ b/src/backend/executor/execPartition.c @@ -976,7 +976,8 @@ ExecInitPartitionInfo(ModifyTableState *mtstate, EState *estate, conv_tl = map_partition_varattnos((List *) action->targetList, firstVarno, partrel, firstResultRel); - conv_tl = adjust_partition_tlist(conv_tl, map); + if (conv_tl != NIL) + conv_tl = adjust_partition_tlist(conv_tl, map); tupdesc = ExecTypeFromTL(conv_tl); /* XXX gotta pfree conv_tl and tupdesc? */ But I wonder if it wouldn't be better to patch adjust_partition_tlist() to return NIL on NIL input, instead, like this: diff --git a/src/backend/executor/execPartition.c b/src/backend/executor/execPartition.c index 1fa4d84c42..6a170eea03 100644 --- a/src/backend/executor/execPartition.c +++ b/src/backend/executor/execPartition.c @@ -1589,6 +1589,9 @@ adjust_partition_tlist(List *tlist, TupleConversionMap *map) AttrMap *attrMap = map->attrMap; AttrNumber attrno; + if (tlist == NIL) + return NIL; + Assert(tupdesc->natts == attrMap->maplen); for (attrno = 1; attrno <= tupdesc->natts; attrno++) { I lean towards the latter myself. -- Álvaro Herrera Valdivia, Chile