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

From Michael Paquier
Subject Re: Support for REINDEX CONCURRENTLY
Date
Msg-id CAB7nPqQa5hVuMqoCNR4pZDPuJAdG8HCqJMp1US-R_ENYXHhr+g@mail.gmail.com
Whole thread Raw
In response to Re: Support for REINDEX CONCURRENTLY  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Support for REINDEX CONCURRENTLY  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
Hi all,

Please find attached a new set of 3 patches for REINDEX CONCURRENTLY (v11).
- 20130214_1_remove_reltoastidxid.patch
-
20130214_2_reindex_concurrently_v11.patch
- 20130214_3_reindex_concurrently_docs_v11.patch
Patch 1 needs to be applied before patches 2 and 3.

20130214_1_remove_reltoastidxid.patch is the patch removing reltoastidxid (approach mentioned by Tom) to allow server to manipulate multiple indexes of toast relations. Catalog views, system functions and pg_upgrade have been updated in consequence by replacing reltoastidxid use by a join on pg_index/pg_class. All the functions of tuptoaster.c now use RelationGetIndexList to fetch the list of indexes on which depend a given toast relation. There are no warnings, regressions are passing (here only an update of rules.out and oidjoins has been necessary).
20130214_2_reindex_concurrently_v11.patch depends on patch 1. It includes the feature with all the fixes requested by Andres in his previous reviews. Regressions are passing and I haven't seen any warnings. in this patch concurrent rebuild of toast indexes is fully supported thanks to patch 1. The kludge used in previous version to change reltoastidxid when swapping indexes is not needed anymore, making swap code far cleaner.
20130214_3_reindex_concurrently_docs_v11.patch includes the documentation of REINDEX CONCURRENTLY. This might need some reshuffling with what is written for CREATE INDEX CONCURRENTLY.

I am now pretty happy with the way implementation is done, so I think that the basic implementation architecture does not need to be changed.

Andres, I think that only a single round of review would be necessary now before setting this patch as ready for committer. Thoughts?

Comments, as well as reviews are welcome.

--
Michael
Attachment

pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]
Next
From: Alexander Law
Date:
Subject: Re: BUG #7493: Postmaster messages unreadable in a Windows console