Message-ID: <52CF45E8.6090208@nasby.net>
Date: Thu, 09 Jan 2014 18:59:20 -0600
From: Jim Nasby <jim@nasby.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Michael Paquier <michael.paquier@gmail.com>,
 PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Subject: Re: REINDEX CONCURRENTLY 2.0
References: 
 <CAB7nPqSTFkuc7dZxCDX4HOTU63YXHRroNv2aoUzyD-Zz_8Z_Zg@mail.gmail.com>
In-Reply-To: 
 <CAB7nPqSTFkuc7dZxCDX4HOTU63YXHRroNv2aoUzyD-Zz_8Z_Zg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers