Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure
Date
Msg-id 1061674.1721752542@sss.pgh.pa.us
Whole thread Raw
In response to BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure
List pgsql-bugs
PG Bug reporting form <noreply@postgresql.org> writes:
> The following script:
> CREATE TABLE t1 (a int);
> CREATE TABLE t2 () INHERITS (t1);
> DROP TABLE t2;
> CREATE TABLE t (a int) PARTITION BY LIST (a);
> ALTER TABLE t ATTACH PARTITION t1 FOR VALUES IN (1);
> INSERT INTO t1 VALUES (1);
> UPDATE t1 SET a = 2 WHERE a = 1

> triggers an assertion failure (due to t1 is not recognized as a leaf
> partition):
> TRAP: failed Assert("rel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE"),

Hmm.  Without the DROP TABLE, the ATTACH would fail:

regression=# ALTER TABLE t ATTACH PARTITION t1 FOR VALUES IN (1);
ERROR:  cannot attach inheritance parent as partition

I observe that in the case given, t1 still has pg_class.relhassubclass
true after the ATTACH PARTITION.  Maybe it'd be wise to force that
false after verifying there are no subclasses?  (I tried fixing it
manually, and that prevents the assertion crash.)

            regards, tom lane



pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #18551: pg_basebackup uses out-of-bounds memory and a segment error occurs during backup
Next
From: Tom Lane
Date:
Subject: Re: BUG #18551: pg_basebackup uses out-of-bounds memory and a segment error occurs during backup