Re: REINDEX CONCURRENTLY 2.0

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: REINDEX CONCURRENTLY 2.0
Дата
Msg-id 52CF45E8.6090208@nasby.net
обсуждение исходный текст
Ответ на REINDEX CONCURRENTLY 2.0  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: REINDEX CONCURRENTLY 2.0  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
Sorry for the lateness of this...

On 11/14/13, 8:40 PM, Michael Paquier wrote:
> +    /*
> +     * Phase 4 of REINDEX CONCURRENTLY
> +     *
> +     * Now that the concurrent indexes have been validated could be used,
> +     * we need to swap each concurrent index with its corresponding old index.
> +     * Note that the concurrent index used for swaping is not marked as valid
> +     * because we need to keep the former index and the concurrent index with
> +     * a different valid status to avoid an implosion in the number of indexes
> +     * a parent relation could have if this operation fails multiple times in
> +     * a row due to a reason or another. Note that we already know thanks to
> +     * validation step that
> +     */
> +

Was there supposed to be more to that comment?

In the loop right below it...

+    /* Swap the indexes and mark the indexes that have the old data as invalid */
+    forboth(lc, indexIds, lc2, concurrentIndexIds)
...
+        CacheInvalidateRelcacheByRelid(relOid);

Do we actually need to invalidate the cache on each case? Is it because we're grabbing a new transaction each time
through?
-- 
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net



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

Предыдущее
От: Marko Tiikkaja
Дата:
Сообщение: Re: array_length(anyarray)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Turning off HOT/Cleanup sometimes