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

From Michael Paquier
Subject Re: Support for REINDEX CONCURRENTLY
Date
Msg-id CAB7nPqQXwXVqAQk_zF_OTmVmHcY7wViGb7YDRydmODh9MSVMHQ@mail.gmail.com
Whole thread Raw
In response to Re: Support for REINDEX CONCURRENTLY  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: Support for REINDEX CONCURRENTLY  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
Please find attached updated version. I also corrected the problem of the query in pg_upgrade when fetching Oids of indexes of toast relation.

On Sun, Mar 10, 2013 at 3:48 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
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.
Oops. Fixed in the patch attached. The bug was in the toastrelidxid patch, not REINDEX CONCURRENTLY core.
 
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.
Yeah, agreed. It is not that much complicated. And this should be done after this patch is finished.

You need to add the description of locking of REINDEX CONCURRENTLY
into mvcc.sgml, I think.
OK, I added some reference to that in the docs. I also added a paragraph about the lock used during process.

+   Rebuild a table concurrently:
+
+<programlisting>
+REINDEX TABLE CONCURRENTLY my_broken_table;
OK... OK... Documentation should be polished more... I changed this paragraph a bit to mention that read and write operations can be performed on the table in this case.
--
Michael
Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Support for REINDEX CONCURRENTLY
Next
From: Fujii Masao
Date:
Subject: Re: odd behavior in materialized view