Horton

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. doc: Describe better handling of indexes in ALTER TABLE ATTACH PARTITION

  2. Ignore invalid indexes when enforcing index rules in ALTER TABLE ATTACH PARTITION

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

    Mohamed ALi <moali.pg@gmail.com> — 2026-05-15T18:30:24Z

    Hi hackers,

Commit fc55c7ff8d1 [1] (back-patched through v11 as e90e9275f56)
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.

The attached patch adds a sentence to the ALTER TABLE reference page
noting that invalid indexes are skipped during this matching and
that a new index is created when no valid equivalent is found.

This is a doc-only change with no code modifications.  I believe it
could be back-patched to all supported branches since the behavior
already exists there.

[1] https://github.com/postgres/postgres/commit/e90e9275f56

-- 
Mohamed Ali
AWS RDS

  2. 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