Re: Support for REINDEX CONCURRENTLY
От | Michael Paquier |
---|---|
Тема | Re: Support for REINDEX CONCURRENTLY |
Дата | |
Msg-id | CAB7nPqQAx+qNEg1Dmao=5FEo6gwKUNziRM+mXSVxQmr0vrP8GQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Support for REINDEX CONCURRENTLY (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: Support for REINDEX CONCURRENTLY
|
Список | pgsql-hackers |
Hi all, Please find attached the patch using MVCC catalogs. I have split the previous core patch into 3 pieces to facilitate the review and reduce the size of the main patch as the previous core patch contained a lot of code refactoring. 0) 20130705_0_procarray.patch, this patch adds a set of generic APIs in procarray.c that can be used to wait for snapshots older than a given xmin, or to wait for some virtual locks. This code has been taken from CREATE/DROP INDEX CONCURRENTLY, and I think that this set of APIs could be used for the implementation os other concurrent DDLs. 1) 20130705_1_index_conc_struct.patch, this patch refactors a bit CREATE/DROP INDEX CONCURRENTLY to create 2 generic APIs for the build of a concurrent index, and the step where it is set as dead. 2) 20130705_2_reindex_concurrently_v28.patch, with the core feature. I have added some stuff here: - isolation tests, (perhaps it would be better to make the DML actions last longer in those tests?) - reduction of the lock used at swap phase from AccessExclusiveLock to ShareUpdateExclusiveLock, and added a wait before commit of swap phase for old snapshots at the end of swap phase to be sure that no transactions will use the old relfilenode that has been swapped after commit - doc update - simplified some APIs, like the removal of index_concurrent_clear_valid - fixed a bug where it was not possible to reindex concurrently a toast relation Patch 1 depends on 0, Patch 2 depends on 1 and 0. Patch 0 can be applied directly on master. The two first patches are pretty simple, patch 0 could even be quickly reviewed and approved to provide some more infrastructure that could be possibly used by some other patches around, like REFRESH CONCURRENTLY... I have also done some tests with the set of patches: - Manual testing, and checked that process went smoothly by taking some manual checkpoints during each phase of REINDEX CONCURRENTLY - Ran make check for regression and isolation tests - Ran make installcheck, and then REINDEX DATABASE CONCURRENTLY on the database regression that remained on server Regards, -- Michael
Вложения
В списке pgsql-hackers по дате отправления: