Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure
От | Tom Lane |
---|---|
Тема | Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure |
Дата | |
Msg-id | 1061674.1721752542@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure
|
Список | 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 по дате отправления: