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 1rttFL-000bN7-JM for pgsql-bugs@arkaria.postgresql.org; Mon, 08 Apr 2024 17:57:32 +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 1rttFK-00Attx-OX for pgsql-bugs@arkaria.postgresql.org; Mon, 08 Apr 2024 17:57:30 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rttFJ-00Attc-QU for pgsql-bugs@lists.postgresql.org; Mon, 08 Apr 2024 17:57:30 +0000 Received: from fhigh2-smtp.messagingengine.com ([103.168.172.153]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rttFC-001bwe-Br for pgsql-bugs@lists.postgresql.org; Mon, 08 Apr 2024 17:57:29 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfhigh.nyi.internal (Postfix) with ESMTP id BC3A11140171; Mon, 8 Apr 2024 13:57:20 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 08 Apr 2024 13:57:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; t=1712599040; x=1712685440; bh=B K/Mg9lJLKkkoXYiDheQRTIJzVhs3J0h1ab2LxAlkYU=; b=UUVtXpYjAZs3BPbTC +imPIhd2k1tyS2Vk3MY3xkcdDavMMf7WQkipdgm6jPSeioEzTkIwRHqIvJh8XqNm Dj/G9cwSjYf/tHcprfGWdB+XGamjwHPXTuufqDDXNUhYd4WzcEjJ1jsRi01UTyLi Cbod4o7WUKMygm9NwyUjAXxvUxEjQJxkdUZ00XUNYcSu4hdBMTDIieltKYH8c9F9 BqqTtHcBnaGA1YwBqH457GgGvOzIqG4KZQS6K5NSHjlRbHt7ipQWNTQsBSMVoEOL 9VIJ/PmsQZYDhwlx04afHShisU3UfizKyJ2q3ply2FB7jI86S9AdOgxqL0r2gldr dJNrQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudegiedguddukecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggugfgjsehtke ertddttdejnecuhfhrohhmpeetlhhvrghrohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhr vgesrghlvhhhrdhnohdqihhprdhorhhgqeenucggtffrrghtthgvrhhnpefhgeefleevtd euleehjeetteevleehheegleetgffhhfdtffehvefghfeuudehhfenucffohhmrghinhep vghnthgvrhhprhhishgvuggsrdgtohhmpdhpohhsthhgrhdrvghsnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhhvghrrhgvsegrlhhv hhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 8 Apr 2024 13:57:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alvh.no-ip.org; s=schmee; t=1712599038; bh=qEPXX9nyoKhwiKJLJyZwmICUvyy/zCJUrNzhmjvd4NE=; h=Date:From:To:Subject:In-Reply-To:From; b=XGZ3Q51YjgrxttJseza1/w3Ebw/2afF5sAFocChv9Oel2FFGv9zb1plj8KEgn5VmL sUAiZesIFUyAvBnamCP0xZPmU5MmApG69SobKYuAM9IooTnoNalPo1Q58JzWNY9fXQ Mgnu4Fqcsg57QF/SX5XNTosWNe7/SVmNuBHnbFeiB8Q17lJrspbfKQ5RbgZPANMlhs qbObfeJXeE4Ki5dRMiivpYLPVCSwk01DVkNmXOIW/b9CIhVzeD5oLlXM6WXGjZayGq Ti6JckayfYFLmeOuG4hAEfjoTaK9WjpG7K4r8oOyEY95V9MGXPxUZzc2ywygIo0tJJ fP+lqB/98L8RQ== Received: by schmee.alvh.no-ip.org (Postfix, from userid 1000) id 38998385; Mon, 8 Apr 2024 19:57:18 +0200 (CEST) Date: Mon, 8 Apr 2024 19:57:18 +0200 From: Alvaro Herrera To: 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: <202404081757.cm2qzva2ywkv@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <18377-e0324601cfebdfe5@postgresql.org> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2024-Mar-05, PG Bug reporting form wrote: > #2 0x0000000000b8748d in ExceptionalCondition (conditionName=0xd25358 > "partdesc->nparts >= pinfo->nparts", fileName=0xd24cfc "execPartition.c", > lineNumber=1943) at assert.c:66 > #3 0x0000000000748bf1 in CreatePartitionPruneState (planstate=0x1898ad0, > pruneinfo=0x1884188) at execPartition.c:1943 > #4 0x00000000007488cb in ExecInitPartitionPruning (planstate=0x1898ad0, > n_total_subplans=2, pruneinfo=0x1884188, > initially_valid_subplans=0x7ffdca29f7d0) at execPartition.c:1803 I had been digging into this crash in late March and seeing if I could find a reliable fix, but it seems devilish and had to put it aside. The problem is that DETACH CONCURRENTLY does a wait for snapshots to disappear before doing the next detach phase; but since pgbench is using prepared mode, the wait is already long done by the time EXECUTE wants to run the plan. Now, we have relcache invalidations at the point where the wait ends, and those relcache invalidations should in turn cause the prepared plan to be invalidated, so we would get a new plan that excludes the partition being detached. But this doesn't happen for some reason that I haven't yet been able to understand. Still trying to find a proper fix. In the meantime, not using prepared plans should serve to work around the problem. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "The ability of users to misuse tools is, of course, legendary" (David Steele) https://postgr.es/m/11b38a96-6ded-4668-b772-40f992132797@pgmasters.net