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 1phEq6-0002Bj-Bc for pgsql-bugs@arkaria.postgresql.org; Tue, 28 Mar 2023 19:18:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1phEq5-0004uJ-6m for pgsql-bugs@arkaria.postgresql.org; Tue, 28 Mar 2023 19:18: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 1phEq4-0004uA-Uj for pgsql-bugs@lists.postgresql.org; Tue, 28 Mar 2023 19:18:36 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1phEq2-00021d-B3 for pgsql-bugs@lists.postgresql.org; Tue, 28 Mar 2023 19:18:35 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 32SJIUkf3653800; Tue, 28 Mar 2023 15:18:30 -0400 From: Tom Lane To: Alexander Lakhin cc: pgsql-bugs@lists.postgresql.org, Peter Eisentraut Subject: Re: BUG #17872: Dropping an attribute of a composite type breaks indexes over the type silently In-reply-to: <65c49195-7117-67c4-5bfe-45ca8832dfe3@gmail.com> References: <17872-d0fbb799dc3fd85d@postgresql.org> <3169550.1679928579@sss.pgh.pa.us> <3182314.1679935605@sss.pgh.pa.us> <1aa2eec0-2017-3870-6d88-228d08c587d3@gmail.com> <3267914.1679941213@sss.pgh.pa.us> <67cb509e-93c7-1c7b-2388-d7e00277b344@gmail.com> <3332642.1679943981@sss.pgh.pa.us> <65c49195-7117-67c4-5bfe-45ca8832dfe3@gmail.com> Comments: In-reply-to Alexander Lakhin message dated "Tue, 28 Mar 2023 19:00:00 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <3653798.1680031110.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Mar 2023 15:18:30 -0400 Message-ID: <3653799.1680031110@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Alexander Lakhin writes: > So I agree, that disabling the drop operation when a composite type has > dependencies is not a harmless change. On the other hand, the code might= be > not ready to deal with the uniqueness assumption violated. Well, corrupt indexes are a fact of life and probably always will be, because collations are such an unpredictable mess. So if we have anyplace that is straight out Assert'ing that uniqueness holds, I'd say that that needs reconsideration. We need to try to turn it into a helpful error message. > #5=C2=A0 0x000055d3131e314f in ExceptionalCondition ( > =C2=A0=C2=A0=C2=A0 conditionName=3DconditionName@entry=3D0x55d313357b85= "next_index =3D=3D nparts", > =C2=A0=C2=A0=C2=A0 fileName=3DfileName@entry=3D0x55d313357887 "partboun= ds.c", lineNumber=3DlineNumber@entry=3D884) at assert.c:66 Hmm. I did not trace this down, but it doesn't look like it's exactly connected to corrupt indexes. regards, tom lane