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

From Tom Lane
Subject Re: BUG #15672: PostgreSQL 11.1/11.2 crashed after dropping a partition table
Date
Msg-id 695.1556056985@sss.pgh.pa.us
Whole thread Raw
In response to BUG #15672: PostgreSQL 11.1/11.2 crashed after dropping a partition table  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #15672: PostgreSQL 11.1/11.2 crashed after dropping apartition table
Re: BUG #15672: PostgreSQL 11.1/11.2 crashed after dropping apartition table
List pgsql-bugs
ISTM we could work around the problem with the attached, which I think
is a good change independently of anything else.

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)

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.

            regards, tom lane

diff --git a/src/backend/commands/indexcmds.c b/src/backend/commands/indexcmds.c
index f8ee4b0..c5c543f 100644
--- a/src/backend/commands/indexcmds.c
+++ b/src/backend/commands/indexcmds.c
@@ -252,8 +252,17 @@ CheckIndexCompatible(Oid oldId,
     if (!ret)
         return false;

-    /* For polymorphic opcintype, column type changes break compatibility. */
+    /* We now need to actually look at the index rel. */
     irel = index_open(oldId, AccessShareLock);    /* caller probably has a lock */
+
+    /* If it's a partitioned index, there is no storage to share. */
+    if (irel->rd_rel->relkind == RELKIND_PARTITIONED_INDEX)
+    {
+        index_close(irel, NoLock);
+        return false;
+    }
+
+    /* For polymorphic opcintype, column type changes break compatibility. */
     for (i = 0; i < old_natts; i++)
     {
         if (IsPolymorphicType(get_opclass_input_type(classObjectId[i])) &&

pgsql-bugs by date:

Previous
From: "Jonathan S. Katz"
Date:
Subject: Re: BUG #15776: Pgpool
Next
From: Tatsuo Ishii
Date:
Subject: Re: BUG #15776: Pgpool