Re: Support for REINDEX CONCURRENTLY
От | Andres Freund |
---|---|
Тема | Re: Support for REINDEX CONCURRENTLY |
Дата | |
Msg-id | 20121207155517.GC8476@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Support for REINDEX CONCURRENTLY (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-hackers |
On 2012-12-07 21:37:06 +0900, Michael Paquier wrote: > Hi all, > > Long time this thread has not been updated... > Please find attached the version 3 of the patch for support of REINDEX > CONCURRENTLY. > The code has been realigned with master up to commit da07a1e (6th December). > > Here are the things modified: > - Improve code to use index_set_state_flag introduced by Tom in commit > 3c84046 > - One transaction is used for each index swap (N transactions if N indexes > reindexed at the same time) > - Fixed a bug to drop the old indexes concurrently at the end of process > > The index swap is managed by switching the names of the new and old indexes > using RenameRelationInternal several times. This API takes an exclusive > lock on the relation that is renamed until the end of the transaction > managing the swap. This has been discussed in this thread and other > threads, but it is important to mention it for people who have not read the > patch. Won't working like this cause problems when dependencies towards that index exist? E.g. an index-based constraint? As you have an access exlusive lock you should be able to just switch the relfilenodes of both and concurrently drop the *_cci index with the old relfilenode afterwards, that would preserve the index states. Right now I think clearing checkxmin is all you would need to other than that. We know we don't need it in the concurrent context. Greetings, Andres Freund --Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: