Re: Partitioned index marked valid while a partition is pending detach

From: surya poondla <suryapoondla4(at)gmail(dot)com>
To: shihao zhong <zhong950419(at)gmail(dot)com>
Cc: michael(at)paquier(dot)xyz, alvherre(at)kurilemu(dot)de, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Partitioned index marked valid while a partition is pending detach
Date: 2026-11-10 00:51:40
Message-ID: CAOVWO5qE9mLwYDBZAGeGxVEqOZ934kcnxJqo8MeDtFU9PeUGkA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Shihao,

Thanks for the findings and the patch.
I tested all three v3 patches together, and 0001 by itself as this could be
backported.
make check and the isolation tests pass in both cases.

With only 0001, if p1's index isn't attached yet, the parent index stays
invalid even after FINALIZE:

create table t (a int) partition by list (a);
create table p1 partition of t for values in (1);
create table p2 partition of t for values in (2);
create unique index ti on only t (a);
create unique index p1_a on p1 (a);
create unique index p2_a on p2 (a);
-- p1 pending detach
alter index ti attach partition p2_a;
alter index ti attach partition p1_a;
ERROR: cannot attach index "p1_a" as a partition of index "ti"
alter table t detach partition p1 finalize; -- ti still invalid

ATExecAttachPartitionIdx() still skips p1, and FINALIZE doesn't revalidate.

Re-attaching p2_a fixes it, but nobody would guess that.
Maybe FINALIZE should revalidate the parent's indexes?
Michael, this affects pushing 0001/0002 alone.

As you noted, without 0003 FINALIZE fails after RENAME or ADD COLUMN
on t, so that stays broken on the back branches. DROP COLUMN is worse as
FINALIZE succeeds but p1 keeps the column as inherited:

create table t (a int, b int) partition by list (a);
create table p1 partition of t for values in (1);
create table p2 partition of t for values in (2);
-- p1 pending detach
alter table t drop column b;
alter table t detach partition p1 finalize;
alter table p1 drop column b;
ERROR: cannot drop inherited column "b"
create table t9 (a int, b int) partition by list (a);
alter table t9 attach partition p1 for values in (1);
TRAP: failed Assert("child_att->attinhcount == 1")

Alvaro's idea of rejecting DDL while a detach is pending looks like what
the back branches need.

With 0003, SET DEFAULT, SET STATISTICS and ALTER COLUMN TYPE on t now
fail with "cannot alter partition "p1" with an incomplete detach", while
ADD COLUMN etc. go through to p1. If that's intended, the spec
should cover it. Also pg_publication_tables now lists p1 but
pg_partition_tree() doesn't.

Regards,
Surya Poondla

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Henson Choi 2026-11-10 00:52:56 Re: [PATCH] Consider window functions when reordering GROUP BY items
Previous Message Masahiko Sawada 2026-11-10 00:18:13 Re: Why is the LSN reported for pg_logical_emit_message() different from other decoded operations?