Re: BUG #15672: PostgreSQL 11.1/11.2 crashed after dropping a partition table

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