Re: Support for REINDEX CONCURRENTLY - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Support for REINDEX CONCURRENTLY
Date
Msg-id CAHGQGwFCJ__z=n-L2HFNeTxUSjr3g=0NLtkdnBOrmoC=fL3UcQ@mail.gmail.com
Whole thread Raw
In response to Re: Support for REINDEX CONCURRENTLY  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Support for REINDEX CONCURRENTLY  (Andres Freund <andres@2ndquadrant.com>)
Re: Support for REINDEX CONCURRENTLY  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Thu, Mar 7, 2013 at 2:17 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>> Indexes:
>>     "hoge_pkey" PRIMARY KEY, btree (i)
>>     "hoge_pkey_cct" PRIMARY KEY, btree (i) INVALID
>>     "hoge_pkey_cct1" PRIMARY KEY, btree (i) INVALID
>>     "hoge_pkey_cct_cct" PRIMARY KEY, btree (i)
>
> Huh, why did that go through? It should have errored out?

I'm not sure why. Anyway hoge_pkey_cct_cct should not appear or should
be marked as invalid, I think.

>> +    The recommended recovery method in such cases is to drop the concurrent
>> +    index and try again to perform <command>REINDEX CONCURRENTLY</>.
>>
>> If an invalid index depends on the constraint like primary key, "drop
>> the concurrent
>> index" cannot actually drop the index. In this case, you need to issue
>> "alter table
>> ... drop constraint ..." to recover the situation. I think this
>> informataion should be
>> documented.
>
> I think we just shouldn't set ->isprimary on the temporary indexes. Now
> we switch only the relfilenodes and not the whole index, that should be
> perfectly fine.

Sounds good. But, what about other constraint case like unique constraint?
Those other cases also can be resolved by not setting ->isprimary?

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Optimizing pglz compressor
Next
From: Tom Lane
Date:
Subject: Re: Writable foreign tables: how to identify rows