Re: Support for REINDEX CONCURRENTLY

On Sat, Mar 9, 2013 at 1:31 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
>
>
> On Sat, Mar 9, 2013 at 1:37 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>
>> + <para>
>> + Concurrent indexes based on a <literal>PRIMARY KEY</> or an
>> <literal>
>> + EXCLUSION</> constraint need to be dropped with <literal>ALTER
>> TABLE
>>
>> Typo: s/EXCLUSION/EXCLUDE
>
> Thanks. This is corrected.
>
>>
>> I encountered a segmentation fault when I ran REINDEX CONCURRENTLY.
>> The test case to reproduce the segmentation fault is:
>>
>> 1. Install btree_gist
>> 2. Run btree_gist's regression test (i.e., make installcheck)
>> 3. Log in contrib_regression database after the regression test
>> 4. Execute REINDEX TABLE CONCURRENTLY moneytmp
>
> Oops. I simply forgot to take into account the case of system attributes
> when building column names in index_concurrent_create. Fixed in new version
> attached.

Thanks for updating the patch!

I found the problem that the patch changed the behavior of
ALTER TABLE SET TABLESPACE so that it moves also
the index on the specified table to new tablespace. Per the
document of ALTER TABLE, this is not right behavior.

I think that it's worth adding new option for concurrent rebuilding
into reindexdb command. It's better to implement this separately
from core patch, though.

You need to add the description of locking of REINDEX CONCURRENTLY
into mvcc.sgml, I think.

+ Rebuild a table concurrently:
+
+<programlisting>
+REINDEX TABLE CONCURRENTLY my_broken_table;

Obviously REINDEX cannot rebuild a table ;)

Regards,

--
Fujii Masao