On Wed, Nov 04, 2026 at 11:54:26PM -0500, shihao zhong wrote: > Agreed. Those two steps check the index after FINALIZE, > and they pass without the fix. So v2 drops them.
The comments still feel a bit confusing to me, but that can be tweaked
infinitely. Saying that, the permutation steps look much cleaner now.
I'll go process this part, barring objections and/or comments of any
kind.
>> On top of that, indexcmds.c uses RelationGetPartitionDesc(true) as
>> well. Could that be a source of problems when creating a unique index
>> on a partitioned table, for example?
>
> Yes. If CREATE UNIQUE INDEX runs while p1 is pending detach, p1 gets
> no index but the parent index is marked valid. An old snapshot can
> then insert duplicate keys into p1 through t. CREATE INDEX ON ONLY
> has the same problem.
>
> This is a little trick because it did change the behavior, I dont think user
> want to create an incorrect PK and running FINALIZE first is easy,
> so I think this is fine to backport.
+ if (PartitionHasPendingDetach(pd->oids[i]))
+ ereport(ERROR,
+ (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
+ errmsg("cannot create index on partitioned table \"%s\"",
+ RelationGetRelationName(rel)),
+ errdetail("Partition \"%s\" has an incomplete detach.",
+ get_rel_name(pd->oids[i])),
+ errhint("Use ALTER TABLE ... DETACH PARTITION ... FINALIZE to
complete the pending detach operation.")));
Still returning an error may be better than breaking a tree
consistency and even worse, break constraints under-the-hood. I am
not sure if there is a better option here.. Alvaro, what do you
think?
--
Michael
signature.asc
Description: PGP signature
