Michael Paquier <michael@paquier.xyz> writes:
> On Fri, Jun 30, 2023 at 07:00:00AM +0300, Alexander Lakhin wrote:
>> Yeah, in regard to that, your patch looks good to me.
>> Thank you!
> Cool, I have fixed this issue, then. The buildfarm looks OK with it.
While going through the commit log to prepare release notes, I was
struck by the fact that this commit (fc55c7ff8 et al) takes the
approach of ignoring invalid child indexes during ATTACH PARTITION:
I have studied a few options here (like the possibility to switch
indisvalid to false for the parent), but came down to the conclusion
that we'd better rely on a simple rule: invalid indexes had better never
be chosen, so as the partition attached uses and creates indexes that
the parent expects.
However, your later fix for handling invalid child indexes during
CREATE PARTITIONED INDEX (cfc43aeb3 et al) does the opposite:
This patch makes sure that indisvalid is set to false on a partitioned
index if at least one of its partition is invalid. The flag is set to
true if *all* its partitions are valid.
This seems inconsistent: why do we behave one way during CREATE and
another during ATTACH? Do we even need fc55c7ff8's logic change
anymore? That is, is it possible that the fixes added by cfc43aeb3
would be enough to resolve the problem (though with a different
outcome that the partitioned index remains invalid after ATTACH
PARTITION)?
Perhaps the week before minor releases is not the time to be fooling
around with this, but it seems like an odd set of choices.
regards, tom lane
