Re: BUG #15672: PostgreSQL 11.1/11.2 crashed after dropping apartition table - Mailing list pgsql-bugs

Thanks for looking at this.

On 2019/04/24 7:03, Tom Lane wrote:
> ISTM we could work around the problem with the attached, which I think
> is a good change independently of anything else.

Agreed.

> There is still an issue, which manifests in both 11 and HEAD, namely
> that the code also propagates the parent index's comment to any child
> indexes.  You can see that with this extended test case:
> 
> create table users(user_id int, name varchar(64), unique (user_id, name)) partition by hash(user_id);    
> comment on index users_user_id_name_key is 'parent index';
> create table users_000 partition of users for values with (modulus 2, remainder 0);
   
 
> create table users_001 partition of users for values with (modulus 2, remainder 1);
   
 
> 
> select relname, relfilenode, obj_description(oid,'pg_class') from pg_class where relname like 'users%';
> alter table users alter column name type varchar(127);                         
> select relname, relfilenode, obj_description(oid,'pg_class') from pg_class where relname like 'users%';
> 
> which gives me (in 11, with this patch)
> 
> ...
>           relname           | relfilenode | obj_description 
> ----------------------------+-------------+-----------------
>  users                      |       89389 | 
>  users_000                  |       89394 | 
>  users_000_user_id_name_key |       89397 | 
>  users_001                  |       89399 | 
>  users_001_user_id_name_key |       89402 | 
>  users_user_id_name_key     |       89392 | parent index
> (6 rows)
> 
> ALTER TABLE
>           relname           | relfilenode | obj_description 
> ----------------------------+-------------+-----------------
>  users                      |       89389 | 
>  users_000                  |       89394 | 
>  users_000_user_id_name_key |       89406 | parent index
>  users_001                  |       89399 | 
>  users_001_user_id_name_key |       89408 | parent index
>  users_user_id_name_key     |       89404 | parent index
> (6 rows)

This may be seen as slightly worse if the child indexes had their own
comments, which would get overwritten by the parent's.

create table pp (a int, b text, unique (a, b)) partition by list (a);
create table pp1 partition of pp for values in (1);
create table pp2 partition of pp for values in (2);
comment on index pp_a_b_key is 'parent index';
comment on index pp1_a_b_key is 'child index 1';
comment on index pp2_a_b_key is 'child index 2';
select relname, relfilenode, obj_description(oid,'pg_class') from pg_class
where relname like 'pp%';
   relname   │ relfilenode │ obj_description
─────────────┼─────────────┼─────────────────
 pp          │       16420 │
 pp1         │       16425 │
 pp1_a_b_key │       16428 │ child index 1
 pp2         │       16433 │
 pp2_a_b_key │       16436 │ child index 2
 pp_a_b_key  │       16423 │ parent index
(6 rows)

alter table pp alter b type varchar(128);
select relname, relfilenode, obj_description(oid,'pg_class') from pg_class
where relname like 'pp%';
   relname   │ relfilenode │ obj_description
─────────────┼─────────────┼─────────────────
 pp          │       16420 │
 pp1         │       16447 │
 pp1_a_b_key │       16450 │ parent index
 pp2         │       16451 │
 pp2_a_b_key │       16454 │ parent index
 pp_a_b_key  │       16441 │ parent index
(6 rows)

> However, I doubt that that's bad enough to justify a major rewrite
> of the ALTER TABLE code in 11 ... and maybe not in HEAD either;
> I wouldn't be too unhappy to leave it to v13.

Yeah, it's probably decent amount of code churn to undertake as a bug-fix.

Thanks,
Amit