On Wed, Oct 31, 2012 at 2:40 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
> > > > > 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. Thanks, Pavan
