Re: BUG #17997: Assert failed in validatePartitionedIndex() when attaching partition index to child of valid index
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Alexander Lakhin <exclusion@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2023-08-02T18:01:40Z
Lists: pgsql-bugs
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
Commits
-
Fix marking of indisvalid for partitioned indexes at creation
- c75c33de5bab 11.21 landed
- dbe0e5c56f31 12.16 landed
- 537b70b82c2c 13.12 landed
- 663b35f2df62 14.9 landed
- cb4ac3e5685f 15.4 landed
- f4691e2e76a4 16.0 landed
- cfc43aeb3810 17.0 landed