Horton

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

Tender Wang <tndrwang@gmail.com>

View thread
From: Tender Wang <tndrwang@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org, Michael Paquier <michael@paquier.xyz>
Date: 2024-06-19T04:29:42Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix ALTER TABLE DETACH for inconsistent indexes

PG Bug reporting form <noreply@postgresql.org> 于2024年6月9日周日 20:58写道：

> 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.
>

Hi Alvaro,

  I tried to fix this issue on v1 patch. Since the related codes were
commited by you.
So do you have some advides about how to fix the reported issue.

Thanks.

-- 
Tender Wang