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 1sNcKn-009ZWN-Nr for pgsql-bugs@arkaria.postgresql.org; Sat, 29 Jun 2024 17:58:01 +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 1sNcJm-009sco-C6 for pgsql-bugs@arkaria.postgresql.org; Sat, 29 Jun 2024 17:56:58 +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 1sNcJl-009scg-Df for pgsql-bugs@lists.postgresql.org; Sat, 29 Jun 2024 17:56:58 +0000 Received: from fout7-smtp.messagingengine.com ([103.168.172.150]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sNcJe-004BEn-8h for pgsql-bugs@lists.postgresql.org; Sat, 29 Jun 2024 17:56:57 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfout.nyi.internal (Postfix) with ESMTP id 71F531380190; Sat, 29 Jun 2024 13:56:47 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sat, 29 Jun 2024 13:56:47 -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=fm2; t=1719683807; x= 1719770207; bh=5kN+31f5cWdsLP2FL8FTvacqSycrs7ZGVUZfJV3XEg4=; b=T u7NjqzGSwpSy4kQ5VzpDLiEsVvMxJGW0WDugr22Y7h7L8BtruHawG5j+FPN016F8 Oa2dfjcDYdq8P3qcNuwnitjCk1b7suowI6W8tO9uVQ+7GdYx6w/g32AFFtiXl4Dc lEtsD1cMreozAb7GcJ80op6xR/5hhdPzumNkIJcMnY1Akv24CEq/3GRJ0aDOg/c4 DVr+FucnIAgpOT3Jj5VEvN88MgsywNgec6YFs3TzH32+FyjbJrjGPFVXJ93t3OPz e8hU0rAvxIY3ypX9JP1ixXHUPmjm+KclNbzW/m4kpvfZygE+OZ+Nt6SXt1f6YlUL jP0d5oebr2Va2kiC61M+Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrtdelgdduudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepvdektdffudfftdffffehfffhjeejhffgieeuueekjeek fffgudffhfduffffueevnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhv hhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 29 Jun 2024 13:56:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alvh.no-ip.org; s=schmee; t=1719683804; bh=9TgKZUcLbwDaO8ygm9Rv4Oq4Xt1r2v0dU51AE1RuVVk=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=LPh9diV1ZUn+xKm5IWXv3xwQvxAcV7Q/kAQMQJ/oaaj1PktDKLl0dW9NM0LXp0Dgg VkNPeQstPXrkIcD+IT5qhb3yzla47F913fCeX7DfevhjzSi4Ym3IcYd4NrMvQ1xbHz NYR1Vv/faNQfYrciqMOyNhR2px7gp4417T876zlqCh1X8t5UTsE3rEfCakdVuF2X2L W7EltnKNBxgivoY0GqLp0qtcFsgte1W3i7L+4CpW06baGieSwYm2rC5f7RqWx/NhcN DDnD3FaiGw1LHZX6dHjvfqtVJIAy30d9QeVT4KhcXz/WIVywG2j9BRyAGLXLzlWqdz uzBmd/FxTithQ== Received: by schmee.alvh.no-ip.org (Postfix, from userid 1000) id 5C4F852B; Sat, 29 Jun 2024 10:56:44 -0700 (PDT) Date: Sat, 29 Jun 2024 19:56:44 +0200 From: Alvaro Herrera To: Laurenz Albe Cc: Michael Paquier , Tender Wang , exclusion@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Message-ID: <202406291756.2d3bmapza7z5@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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 On 2024-Jun-29, Laurenz Albe wrote: > My example that triggered this assert runs just fine on v16. Well, in a build without assertions enabled then yes it doesn't crash. But if you do have asserts enabled in 16, it does crash. > So while an error is clearly better than a crash, that would constitute > a regression. Is that really unavoidable? It would be very unfortunate > if the only way to detach a partition would be to drop some indexes first... The error would not occur on detach, but on attach, and it'd be intended to prevent an inconsistent situation. I'm proposing that on older branches we do what Tender proposed elsewhere, namely to cope with the detach without crashing (and without leaving inconsistent catalog state, such as bogus coninhcount values). -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "Pero la cosa no es muy grave ..." (le petit Nicolas -- René Goscinny)