Re: Partitioned index marked valid while a partition is pending detach

Hi Michael,

Thanks for reviewing my patch..

> The last "s2detachfinal s1valid" steps in the new permutation don't
> seem strongly necessary if you want to check your case. Or do you
> specifically want to have coverage of a FINALIZE with an attached
> index? I would cut these two steps, just wondering if you have an
> argument in favor of keeping them.

Agreed. Those two steps check the index after FINALIZE,
and they pass without the fix. So v2 drops them.

> 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.

Building the index on p1 does not work, because the rest of ALTER
TABLE skips p1. ADD PRIMARY KEY would fail, since p1 gets no NOT NULL
constraint. So 0003 makes CREATE INDEX on t fail while a partition
is pending detach, with the same hint ALTER TABLE gives.

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.

Thanks,
Shihao