Hi Michael, Sami, Haibo,
Thank you all for the reviews and for committing the fix (9d3e094f12).
I'm glad to see this backpatched through PostgreSQL 14.
Sami's targeted approach — only calling validatePartitionedIndex()
when the index is already attached AND the parent is currently
invalid — is clean and avoids the concerns Haibo raised about
turning the no-op path into a generic validation hook. Good call.
I noticed that the commit did not include a documentation update
for ALTER INDEX ATTACH PARTITION.
There is no mention that re-running the command on an already-attached
index will attempt to validate the parent. Users who hit this bug
would have no way to discover the recovery path from the docs alone —
they would need to find the mailing list thread or read the commit
message.
I have attached a small doc-only patch that adds a paragraph to the
ALTER INDEX documentation:
"If the named index is already attached to the altered index, the
command will attempt to validate the parent index if the parent
is currently invalid."
This applies on top of current HEAD (which includes 9d3e094f12).
Since the code change was backpatched to 14, the doc update should
probably be backpatched to the same branches.
Thanks,
Mohamed Ali
AWS RDS
On Wed, Apr 22, 2026 at 3:33 AM Sami Imseih <samimseih@gmail.com> wrote:
>
> > > One thing that I'm tempted to add is more scans to check indisvalid
> > > across these commands, particularly after the individual ATTACH
> > > PARTITION bits on each individual index.
>
> That works.
>
> > > A second thing. Do you think that it would be worth adding a
> > > partitioned table that has no leaves in some portion of the test? I
> > > was thinking about a partitioned table called idxpart2 attached to
> > > idxpart in the first part of the test. I've found this pattern
> > > usually useful for this area of the code when recursing with
> > > validatePartitionedIndex() from a parent.
>
> Good idea.
>
> > Both things have been added to the tests, and applied the result down
> > to v14. The patch was able to apply cleanly across the board, without
> > conflicts. That's rare, these days..
>
> Sorry for the late reply, and thanks for getting this committed!
>
> --
> Sami Imseih
> Amazon Web Services (AWS)