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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: exclusion(at)gmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Subject: Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure
Date: 2024-07-23 16:35:42
Message-ID: 1061674.1721752542@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2024-07-23 16:41:57 Re: BUG #18551: pg_basebackup uses out-of-bounds memory and a segment error occurs during backup
Previous Message PG Bug reporting form 2024-07-23 15:37:53 BUG #18551: pg_basebackup uses out-of-bounds memory and a segment error occurs during backup