Thread: BUG #16700: Child table dependency loss after moving out of and back into the inheritance tree

The following bug has been logged on the website:

Bug reference:      16700
Logged by:          Daniel Vérité
Email address:      daniel@manitou-mail.org
PostgreSQL version: 9.6.18
Operating system:   Linux
Description:

Hi,

When dropping a column in a parent table, the change is propagated to child
tables.
But when a child has been moved out of the hierarchy and then back into
it,
this propagation appears to no longer work for that child table.

Below is a reproducer I've tried with both the current devel version and 9.6
(9.6 is the version I'm having the issue with in production). The result is
the same.


DROP TABLE  IF EXISTS parent_tbl CASCADE;

CREATE TABLE parent_tbl(f1 int, f2 int, f3 int);

CREATE TABLE child1_tbl() INHERITS(parent_tbl);
CREATE TABLE child2_tbl() INHERITS(parent_tbl);
CREATE TABLE child3_tbl() INHERITS(parent_tbl);

ALTER TABLE child2_tbl NO INHERIT parent_tbl;
ALTER TABLE child2_tbl INHERIT parent_tbl;

ALTER TABLE parent_tbl DROP COLUMN f2;

\d child*_tbl

             Table "public.child1_tbl"
 Column |  Type   | Collation | Nullable | Default 
--------+---------+-----------+----------+---------
 f1     | integer |           |          | 
 f3     | integer |           |          | 
Inherits: parent_tbl

             Table "public.child2_tbl"
 Column |  Type   | Collation | Nullable | Default 
--------+---------+-----------+----------+---------
 f1     | integer |           |          | 
 f2     | integer |           |          | 
 f3     | integer |           |          | 
Inherits: parent_tbl

             Table "public.child3_tbl"
 Column |  Type   | Collation | Nullable | Default 
--------+---------+-----------+----------+---------
 f1     | integer |           |          | 
 f3     | integer |           |          | 
Inherits: parent_tbl

It's surprising that dropping the parent_tbl.f2 column does not cascade into
child2_tbl, even though child2_tbl is a member of the hierarchy.
Is it a bug?

PG Bug reporting form <noreply@postgresql.org> writes:
> When dropping a column in a parent table, the change is propagated to child
> tables.
> But when a child has been moved out of the hierarchy and then back into
> it,
> this propagation appears to no longer work for that child table.

I believe this is operating as designed.  When you dis-inherit the child
table, all its columns go to attinhcount = 0 and therefore get attislocal
set to true (since the alternative would be to drop them).  Re-inheriting
increments attinhcount, but attislocal remains true.  Then the DROP COLUMN
on the parent reduces attinhcount back to zero, but since attislocal is
still true, the column is not dropped.

One could argue that the re-inherit step ought to clear attislocal.
But I think that would just move the weird behaviors somewhere else,
primarily because there's no principled reason for ALTER ... INHERIT
to assume that the column never had a local definition.

In any case, this mechanism was intentionally designed to err on the
side of not throwing away data in questionable cases, and I think
that's a smart bias to have.

I believe there was a pretty thorough discussion of all this back when
we invented the attinhcount/attislocal tracking mechanism (before that,
there were some very unpleasant corner cases).  You could try digging
in the archives if you want more detail.

            regards, tom lane