Re: Problem Observed in behavior of Create Index Concurrently and Hot Update - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Re: Problem Observed in behavior of Create Index Concurrently and Hot Update
Date
Msg-id CABOikdMKX7LJvsh8MmY0U2CyZOgVjdrHhE7KtZyGjoBcy_HGvA@mail.gmail.com
Whole thread Raw
In response to Re: Problem Observed in behavior of Create Index Concurrently and Hot Update  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers



On Wed, Oct 31, 2012 at 2:40 PM, Simon Riggs <simon@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.


Simon,

I hope this hasn't fallen through the cracks.

Thanks,
Pavan
 

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY
Next
From: Michael Paquier
Date:
Subject: Re: [PATCH 05/14] Add a new relmapper.c function RelationMapFilenodeToOid that acts as a reverse of RelationMapOidToFilenode