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

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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