Re: BUG #17872: Dropping an attribute of a composite type breaks indexes over the type silently - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #17872: Dropping an attribute of a composite type breaks indexes over the type silently
Date
Msg-id 3653799.1680031110@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #17872: Dropping an attribute of a composite type breaks indexes over the type silently  (Alexander Lakhin <exclusion@gmail.com>)
List pgsql-bugs
Alexander Lakhin <exclusion@gmail.com> 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  0x000055d3131e314f in ExceptionalCondition (
>      conditionName=conditionName@entry=0x55d313357b85 "next_index == nparts",
>      fileName=fileName@entry=0x55d313357887 "partbounds.c", lineNumber=lineNumber@entry=884) 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



pgsql-bugs by date:

Previous
From: Andres Freund
Date:
Subject: Re: BUG #17871: JIT during postgresql_fdw remote_estimates EXPLAIN have very negatively effect on planning time
Next
From: Tom Lane
Date:
Subject: Re: CTE subquery referencing phantom records