Re: REINDEX CONCURRENTLY 2.0 - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: REINDEX CONCURRENTLY 2.0
Date
Msg-id 52CF45E8.6090208@nasby.net
Whole thread Raw
In response to REINDEX CONCURRENTLY 2.0  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: REINDEX CONCURRENTLY 2.0  (Michael Paquier <michael.paquier@gmail.com>)
List 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 by date:

Previous
From: Marko Tiikkaja
Date:
Subject: Re: array_length(anyarray)
Next
From: Robert Haas
Date:
Subject: Re: Turning off HOT/Cleanup sometimes