Re: BUG #19580: Can not FINALIZE detach partition. Table in stuck

On 2026-Jul-25, PG Bug reporting form wrote:

> drop table if exists t;
> CREATE TABLE t (id bigint GENERATED BY DEFAULT AS IDENTITY, reg int, primary
> key (id, reg)) PARTITION BY RANGE (id);
> CREATE TABLE t1 PARTITION OF t FOR VALUES FROM (1) TO (20) PARTITION BY
> RANGE(reg);
> CREATE TABLE t11 PARTITION OF t1 FOR VALUES FROM (1) TO (10);
> ALTER TABLE t DETACH PARTITION t1;
> ALTER TABLE t ATTACH PARTITION t1 FOR VALUES FROM (1) TO (20);
>
> "generated by default as identity" was added only to t1 and not in t11.

Hmm, I think the bug here is that ATTACH PARTITION seems to have
neglected to add the GENERATED BY expression to that column of t11.
When the table was initially created in line 4, the generation
expression was there, but DETACH removes it, and then ATTACH doesn't put
it back.

(If you start this sequence from scratch and try the DETACH CONCURRENTLY
at after creating t11 but before doing the DETACH/ATTACH dance, it seems
to work properly.)

> But, the problem is:
> ALTER TABLE t DETACH PARTITION t1 CONCURRENTLY;
> ERROR: column "id" of relation "t11" is not an identity column

Even if the above is fixed, maybe this should somehow be made a WARNING
instead of a hard error, to avoid brittleness in DETACH in cases of
bogus catalog contents.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"XML!" Exclaimed C++. "What are you doing here? You're not a programming
language."
"Tell that to the people who use me," said XML.
https://burningbird.net/the-parable-of-the-languages/