Apache Cloudberry version
main; REL_2_STABLE
What happened
UPDATE of a distribution-key column is rejected for a table that has inheritance children:
ERROR: can't split update for inherit table: pinh (preptlist.c:140)
The error persists after all child tables are dropped. The check relies on pg_class.relhassubclass, which PostgreSQL does not clear when the last child is dropped; only ANALYZE or VACUUM clears it lazily. As a result, a plain table with no children refuses to update its distribution key until somebody runs ANALYZE on it.
On REL_2_STABLE, this happens with the Postgres planner (optimizer = off). With GPORCA, the same UPDATE after DROP TABLE cinh succeeds.
What you think should happen instead
Once the table has no inheritance children, updating its distribution key should work as it does for any other table. The check should look at the actual children (for example find_inheritance_children() / pg_inherits), not at relhassubclass, which is only a hint.
How to reproduce
create table pinh(a int, b int) distributed by (b);
create table cinh() inherits (pinh);
insert into pinh values (1,1);
update pinh set a = a + 1; -- OK, not a distribution key
update pinh set b = b + 1; -- ERROR: can't split update for inherit table: pinh
drop table cinh;
select count(*) from pg_inherits where inhparent = 'pinh'::regclass; -- 0, no children
select relhassubclass from pg_class where oid = 'pinh'::regclass; -- t, stale flag
update pinh set b = b + 1; -- still ERROR: can't split update for inherit table: pinh
analyze pinh;
select relhassubclass from pg_class where oid = 'pinh'::regclass; -- f
update pinh set b = b + 1; -- UPDATE 1
Operating System
any
Anything else
No response
Are you willing to submit PR?
Code of Conduct
Apache Cloudberry version
main; REL_2_STABLE
What happened
UPDATEof a distribution-key column is rejected for a table that has inheritance children:The error persists after all child tables are dropped. The check relies on
pg_class.relhassubclass, which PostgreSQL does not clear when the last child is dropped; onlyANALYZEorVACUUMclears it lazily. As a result, a plain table with no children refuses to update its distribution key until somebody runsANALYZEon it.On REL_2_STABLE, this happens with the Postgres planner (
optimizer = off). With GPORCA, the sameUPDATEafterDROP TABLE cinhsucceeds.What you think should happen instead
Once the table has no inheritance children, updating its distribution key should work as it does for any other table. The check should look at the actual children (for example
find_inheritance_children()/pg_inherits), not atrelhassubclass, which is only a hint.How to reproduce
Operating System
any
Anything else
No response
Are you willing to submit PR?
Code of Conduct