Re: Support for REINDEX CONCURRENTLY

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Support for REINDEX CONCURRENTLY
Дата
Msg-id CAB7nPqQa5hVuMqoCNR4pZDPuJAdG8HCqJMp1US-R_ENYXHhr+g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Support for REINDEX CONCURRENTLY  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Support for REINDEX CONCURRENTLY  (Fujii Masao <masao.fujii@gmail.com>)
Список 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
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]
Следующее
От: Alexander Law
Дата:
Сообщение: Re: BUG #7493: Postmaster messages unreadable in a Windows console