Re: [PATCH] Fix: Partitioned parent index remains invalid after child indexes are repaired

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: Haibo Yan <tristan(dot)yim(at)gmail(dot)com>, Mohamed ALi <moali(dot)pg(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] Fix: Partitioned parent index remains invalid after child indexes are repaired
Date: 2026-04-13 22:18:33
Message-ID: ad1rubGPdHxNnDh5@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Apr 11, 2026 at 11:10:54AM -0500, Sami Imseih wrote:
> I don't think that a REINDEX should attempt to set the parent index indisvalid.
> It seems the responsibility for this falls squarely on the ATTACH
> PARTITION command,
> as it currently does.

Relying on REINDEX is not optimal, as it would mean that all the
partitioned indexes would need to be updated before flipping the flag.
If the indisvalid flags of the partitions are already true, this would
be a huge waste of resources.

> Would the right solution here be to try to have the ATTACH PARTITION check if
> the parent index is not valid, then validatePartitionedIndex() ?

This may be a backpatchable thing, even if it requires one to detach
one partition before attaching it again, or attach a fake partition to
force a flip of the flag, before detaching this fake partition.

One better alternative that I could think of is a new flavor of ALTER
TABLE, like a ALTER TABLE foo VALIDATE PARTITION (no partition name
here) focused on flipping the indisvalid flags? This would not be
backpatchable, but it would make the whole flow lighter by not
requiring a redefinition of one partition.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2026-04-13 22:52:25 Re: Row pattern recognition
Previous Message John Mikk 2026-04-13 21:11:34 POC: Comparison of partitioning key values