On Sat, Mar 9, 2013 at 1:31 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > > > On Sat, Mar 9, 2013 at 1:37 AM, Fujii Masao <masao.fu...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
