> > diff --git a/src/backend/utils/cache/relcache.c > b/src/backend/utils/cache/relcache.c > index a59950e..9cadb3f 100644 > --- a/src/backend/utils/cache/relcache.c > +++ b/src/backend/utils/cache/relcache.c > @@ -3355,6 +3355,12 @@ RelationGetIndexList(Relation relation) > oidvector *indclass; > bool isnull; > > + /* > + * Ignore any indexes that are currently being dropped > + */ > + if (!index->indisvalid && !index->indisready) > + continue; > + > /* Add index's OID to result list in the proper order */ > result = insert_ordered_oid(result, index->indexrelid);
Agreed, will fix.
Thanks Simon.
Looks like a severe data corruption issue. Is there a minor release planned in near future or would this need one ?
Please let me know if you need any help with this. I investigated this a bit before posting my analysis (just to ensure that its not a HOT's bug), but since it involved DROP INDEX CONCURRENTLY, thought it will best be addressed by you.
