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 1nafG0-0007NZ-MV for pgsql-hackers@arkaria.postgresql.org; Sat, 02 Apr 2022 15:01:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nafFz-0006Tt-HZ for pgsql-hackers@arkaria.postgresql.org; Sat, 02 Apr 2022 15:01:39 +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 1nafFz-0006Tj-8J for pgsql-hackers@lists.postgresql.org; Sat, 02 Apr 2022 15:01:39 +0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nafFw-0004hB-SL for pgsql-hackers@postgresql.org; Sat, 02 Apr 2022 15:01:38 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 95C7D5C0045; Sat, 2 Apr 2022 11:01:33 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sat, 02 Apr 2022 11:01:33 -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=7V6HJfAznGKfFlki67G5OM4A/+K6KP3wK0KmV5BcZL0=; b=e+iupPvx vh+teT+7b2GKX8ouZcLSNHyh7VzvQkyI9LaD7jOTBUEbhUVsZKH58YcKkP294+ae piEAQM7m7rZ7IcNo2lrlvPoMAaYHdreQLD9cEjt4SNUayDqhKQjm1BVfrF2FW1b3 gtne7RI/kLtdC/U7mI1hfMCdpMgruvYWZ2SoYRW2djKbpQZ4RNNwbrxCYLd6K8/T UyUq6nsT1VYv4X+x0NRvu/JnmP+CqCqv4LhZ4nls9/ZpT3FMwAs4GYge5tl4z6nC s/obefeySIRze/VFisp4oTjSRqr7xo8hqfB1D13yQ19BoEJH6EMuTY6L2LZzKnqD V2gavwegoMs2Gw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudeikedgkeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpedujeevjeffjeevuddutedvkeeiueeitddvieelfeekveej udefgeeuvdejhfeuleenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 2 Apr 2022 11:01:31 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 1070D2A1C14; Sat, 2 Apr 2022 12:02:01 -0300 (-03) Date: Sat, 2 Apr 2022 17:02:01 +0200 From: Alvaro Herrera To: Daniel Gustafsson Cc: Ranier Vilela , Peter Eisentraut , Justin Pryzby , Amit Langote , Japin Li , Zhihong Yu , simon.riggs@enterprisedb.co, Tomas Vondra , Daniel Westermann , Erik Rijkers , Jaime Casanova , Andres Freund , PostgreSQL Hackers Subject: Re: support for MERGE Message-ID: <202204021502.hxkog726fulu@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3D47D785-0788-43BE-93B4-06B13B8722FA@yesql.se> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022-Mar-31, Daniel Gustafsson wrote: > > On 31 Mar 2022, at 19:38, Ranier Vilela wrote: > > > I think that there is an oversight at 7103ebb > > There is no chance of Assert preventing this bug. > > This seems reasonable from brief reading of the code, NULL is a legitimate > value for the map and that should yield an empty list AFAICT. There's no bug here and this is actually intentional: if the map is NULL, this function should not be called. In the code before this commit, there was an assert that this variable was not null: static List * adjust_partition_colnos(List *colnos, ResultRelInfo *leaf_part_rri) { - List *new_colnos = NIL; TupleConversionMap *map = ExecGetChildToRootMap(leaf_part_rri); ! AttrMap *attrMap; ListCell *lc; ! Assert(map != NULL); /* else we shouldn't be here */ ! attrMap = map->attrMap; foreach(lc, colnos) { We could add an Assert that map is not null in the new function, but really there's no point: if the map is null, we'll crash just fine in the following line. I would argue that we should *remove* the Assert() that I left in adjust_partition_colnos_with_map. Even if we wanted to make the function handle the case of a NULL map, then the right fix is not to return NIL, but rather we should return the original list. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/