Thread

Re: [PATCH] doc: Document that invalid indexes are skipped during ATTACH PARTITION

Sami Imseih <samimseih@gmail.com> — 2026-05-15T19:57:30Z

Hi,

> added logic to skip invalid indexes when ALTER TABLE ... ATTACH
> PARTITION matches partition indexes to the parent table's indexes.
> This prevents choosing an incomplete partitioned index as a match,
> which could create inconsistent partition index trees.
>
> However, this behavior was never documented.  A user who has an
> invalid index on a partition (e.g., from a failed CREATE INDEX
> CONCURRENTLY) may be surprised when ATTACH PARTITION silently
> creates a new index instead of attaching the existing one.

Rght.

-- Before ATTACH: index marked invalid
    indexrelid   | indisvalid
  ---------------+------------
   child_val_idx | f
  (1 row)

-- After ATTACH: invalid index skipped, new one created
     indexrelid   | indisvalid
  ----------------+------------
   child_val_idx  | f
   child_val_idx1 | t
  (2 rows)

The current documentation says "or, if an equivalent index already exists,
it will be attached to the target table's...", but makes no mention that this
equivalent index must be valid. What about we just reinforce that point
in the current lines of documentation. I also think it's better to flip things
around where the positive case of an equivalent index being found goes
first.

```
-      For each index in the target table, a corresponding
-      one will be created in the attached table; or, if an equivalent
-      index already exists, it will be attached to the target table's index,
-      as if <command>ALTER INDEX ATTACH PARTITION</command> had been executed.
+      For each index in the target table, if a valid equivalent
+      index already exists in the partition, it will be attached
+      to the target table's index, as if
+      <command>ALTER INDEX ATTACH PARTITION</command> had been executed;
+      otherwise, a corresponding one will be created.
```

What do you think?

--
Sami