Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sGh1A-00G1U6-52 for pgsql-bugs@arkaria.postgresql.org; Mon, 10 Jun 2024 15:33:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sGh17-00DXKb-PQ for pgsql-bugs@arkaria.postgresql.org; Mon, 10 Jun 2024 15:33:06 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sGh16-00DXK9-Hx for pgsql-bugs@lists.postgresql.org; Mon, 10 Jun 2024 15:33:06 +0000 Received: from fhigh2-smtp.messagingengine.com ([103.168.172.153]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sGh13-000eQ7-V7 for pgsql-bugs@lists.postgresql.org; Mon, 10 Jun 2024 15:33:04 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 73FDB114011D; Mon, 10 Jun 2024 11:33:00 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 10 Jun 2024 11:33:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1718033580; x= 1718119980; bh=xkeb16ggwBvHkdGxyYE3BFZI5ItK4TdLJZctDHZXaQ0=; b=m 1OrsPHyB++ft69fH+/YXyR2BoybUBbcWKvNh4+WW17cXOwJgPWmb2+ViXZsiZorU trUJqHXpvgLmK4jSv1kKoSt6luinhh1ttWNJXVI9owwlvQ4a5hbf4NKu9geU/ITH t6FyPYDDQDA1P/fFVRyz2o5swbCqT0ResJych1xTJbrkvNz8GHO0d5RqFlcoYFtU FanvemTgiNnFjgOcX8w6q8vLCioa0HsJUbPUxDbjgMggvKTvUzX7bZ0DzBMduv5D F0jgcCZVk9MziZR5RyKaFGEuB2Keya9fcUigzTCTMd3a9GRGPjirUze86Wdfx4JX FwbgtaQ3STBf6juCTihVg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedutddgkeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkgggtugfgjgesmhekreertddtjeenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepudelkeekgfdttdettdekgfduvdeiffelteegjeeihfet heekveeftedtuddvhfeunecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhv hhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 10 Jun 2024 11:32:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alvh.no-ip.org; s=schmee; t=1718033576; bh=YcGj9oXkckdnO1FNkzmMli3IRhgantln21mydMqnctI=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=LVQKRaCcTJXApQNV0LP+QGf0Y4uchaY55KrbtZGNBJgWZ8rG7s7NvkoeT/jHUTAE/ SC6tpmothW0FQYTykQn1NJOZ2yT7WDLdXM1jlYbRIotWGYOu7k4FvluecqIZTWCiw1 8NCH0erXDEvrDHXq/8FG6SQ8IOQ7lQrzNVRZrYm3a7e48FTDZk7FFRkXfpMunABP1C LdxnuC4w3UIAwv8xqEeBw/4GubiILbsF5WCyBrTE+MpZggdQs5I4vi8TJHUhTj2KK3 0X05LbebJ0qcy17O6kLwIDYmj1Gpx53BsYN2/Aycn3TAWzmZj1YhCeUbaHzZYtg7xn 0o+Kvt/sz87Gw== Received: by schmee.alvh.no-ip.org (Postfix, from userid 1000) id CB082D1; Mon, 10 Jun 2024 08:32:56 -0700 (PDT) Date: Mon, 10 Jun 2024 17:32:56 +0200 From: Alvaro Herrera To: Tender Wang Cc: 1026592243@qq.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18377: Assert false in "partdesc->nparts >= pinfo->nparts", fileName="execPartition.c", lineNumber=1943 Message-ID: <202406101532.g7bjnhxveuur@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="6kkovcx3obkugakc" 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 --6kkovcx3obkugakc Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On 2024-May-22, Tender Wang wrote: > I have tested this patch locally and did not encounter any failures. > I will take time to look the patch in detail and consider the issues you > mentioned. Thanks for testing! I've spend some more time playing with this, and I confirmed my fears that it's possible to hit the case where one partition is added and another is removed, so the count of partitions is the same, yet their OIDs don't match (problem [2] in my previous email). This means we're forced to memcmp() the arrays even when nparts match. We can reuse the maps if the partition OID arrays are bitwise identical, otherwise we map the partitions one by one into subpart_map / subplan_map. I ended up splitting the code fix in two parts, one for RelationBuildPartitionDesc and the other for CreatePartitionPruneState, because the two areas being touch have independent bugs that seem more easily explained separately. However, I was unable to trigger the bug that 0001 fixes without involving the code in 0002. The commit messges should explain each bug and fix in enough detail, I hope. I'm not happy about the comment changes in 0002: I think I'm losing some of the original comments that should perhaps be retained. I'll look into that, but I'll push 0001 soon. (Both these patches are needed from 14 onwards, where DETACH CONCURRENTLY was added.) -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "In fact, the basic problem with Perl 5's subroutines is that they're not crufty enough, so the cruft leaks out into user-defined code instead, by the Conservation of Cruft Principle." (Larry Wall, Apocalypse 6) --6kkovcx3obkugakc Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v2-0001-Fix-creation-of-partition-descriptor-during-concu.patch"