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

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2024-Jul-23, Tom Lane wrote:
>> 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.)

> Yeah, that seems to work.  We can do that essentially for free in
> StorePartitionBound(), like in the attached (which was taken in 14).

Looks sane.

> I'd add Alexander's script as a test too, somewhere near the bottom of
> create_table.sql.

Personally I'd include this in the existing alter_table.sql test case,
to save a few steps:

 -- check that the table being attached is not part of regular inheritance
 CREATE TABLE parent (LIKE list_parted);
 CREATE TABLE child () INHERITS (parent);
 ALTER TABLE list_parted ATTACH PARTITION child FOR VALUES IN (1);
 ERROR:  cannot attach inheritance child as partition
 ALTER TABLE list_parted ATTACH PARTITION parent FOR VALUES IN (1);
 ERROR:  cannot attach inheritance parent as partition
+DROP TABLE child;
+-- now it should work
+ALTER TABLE list_parted ATTACH PARTITION parent FOR VALUES IN (1);
+-- test insert/update, per bug #18550
+INSERT INTO parent ...
+UPDATE parent ...
 DROP TABLE parent CASCADE;

            regards, tom lane