Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert

The following bug has been logged on the website:

Bug reference:      18500
Logged by:          Alexander Lakhin
Email address:      exclusion@gmail.com
PostgreSQL version: 17beta1
Operating system:   Ubuntu 22.04
Description:       

The following script:
CREATE TABLE t (a integer) PARTITION BY RANGE (a);
CREATE TABLE tp (a integer PRIMARY KEY);
ALTER TABLE t ATTACH PARTITION tp FOR VALUES FROM (0) TO (1000);

CREATE UNIQUE INDEX t_a_idx ON t (a);
ALTER INDEX t_a_idx ATTACH PARTITION tp_pkey;

\d+ t*
ALTER TABLE t DETACH PARTITION tp;

triggers an assertion failure as below:
...
              Partitioned index "public.t_a_idx"
 Column |  Type   | Key? | Definition | Storage | Stats target
--------+---------+------+------------+---------+--------------
 a      | integer | yes  | a          | plain   |
unique, btree, for table "public.t"
Partitions: tp_pkey
Access method: btree
...
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
connection to server was lost

TRAP: failed Assert("constrForm->coninhcount == 0"), File:
"pg_constraint.c", Line: 873, PID: 3272276
...
#5  0x000055b26dc9b76f in ExceptionalCondition (
    conditionName=conditionName@entry=0x55b26dd2d254
"constrForm->coninhcount == 0",
    fileName=fileName@entry=0x55b26dd2d230 "pg_constraint.c",
lineNumber=lineNumber@entry=873) at assert.c:66
#6  0x000055b26d8687d7 in ConstraintSetParentConstraint
(childConstrId=16392, parentConstrId=parentConstrId@entry=0,
    childTableId=childTableId@entry=0) at pg_constraint.c:873
#7  0x000055b26d9361c7 in DetachPartitionFinalize
(rel=rel@entry=0x7f84a051d4b8, partRel=partRel@entry=0x7f84a0514428,
    concurrent=concurrent@entry=false,
defaultPartOid=defaultPartOid@entry=0) at tablecmds.c:19306
#8  0x000055b26d94449a in ATExecDetachPartition
(wqueue=wqueue@entry=0x7fff8d338780, tab=tab@entry=0x55b26fcd6f90,
    rel=rel@entry=0x7f84a051d4b8, name=<optimized out>, concurrent=false) at
tablecmds.c:19140
#9  0x000055b26d944fe0 in ATExecCmd (wqueue=wqueue@entry=0x7fff8d338780,
tab=tab@entry=0x55b26fcd6f90,
    cmd=<optimized out>, lockmode=lockmode@entry=8,
cur_pass=cur_pass@entry=AT_PASS_MISC,
    context=context@entry=0x7fff8d338890) at tablecmds.c:5515
...

Without asserts enabled, DETACH executed with no error.

Reproduced on REL_11_STABLE .. master.