Re: Problem Observed in behavior of Create Index Concurrently and Hot Update
| От | Pavan Deolasee |
|---|---|
| Тема | Re: Problem Observed in behavior of Create Index Concurrently and Hot Update |
| Дата | |
| Msg-id | CABOikdO-VN2Bq+jG2MJH4yT5O+CHng-iUmJ0YZ7FW17xd-Fc_A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Problem Observed in behavior of Create Index Concurrently and Hot Update (Simon Riggs <simon@2ndQuadrant.com>) |
| Список | pgsql-hackers |
On Wed, Oct 31, 2012 at 2:40 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
Agreed, will fix.
>
> 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);
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
В списке pgsql-hackers по дате отправления: