Fix marking of indisvalid for partitioned indexes at creation
commitcfc43aeb3810ebaa8dbda4807046a4c953d9e992
authorMichael Paquier <michael@paquier.xyz>
Fri, 30 Jun 2023 04:54:48 +0000 (30 13:54 +0900)
committerMichael Paquier <michael@paquier.xyz>
Fri, 30 Jun 2023 04:54:48 +0000 (30 13:54 +0900)
tree8493a4f565369145a963d8d5baf4004f85b62a8a
parentc951e9042dd12db80cac4e9a50f198a1eead2036
Fix marking of indisvalid for partitioned indexes at creation

The logic that introduced partitioned indexes missed a few things when
invalidating a partitioned index when these are created, still the code
is written to handle recursions:
1) If created from scratch because a mapping index could not be found,
the new index created could be itself invalid, if for example it was a
partitioned index with one of its leaves invalid.
2) A CCI was missing when indisvalid is set for a parent index, leading
to inconsistent trees when recursing across more than one level for a
partitioned index creation if an invalidation of the parent was
required.

This could lead to the creation of a partition index tree where some of
the partitioned indexes are marked as invalid, but some of the parents
are marked valid, which is not something that should happen (as
validatePartitionedIndex() defines, indisvalid is switched to true for a
partitioned index iff all its partitions are themselves valid).

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.

The regression test added in this commit abuses of a failed concurrent
index creation, marked as invalid, that maps with an index created on
its partitioned table afterwards.

Reported-by: Alexander Lakhin
Reviewed-by: Alexander Lakhin
Discussion: https://postgr.es/m/14987634-43c0-0cb3-e075-94d423607e08@gmail.com
Backpatch-through: 11
src/backend/commands/indexcmds.c
src/test/regress/expected/indexing.out
src/test/regress/sql/indexing.sql