Re: Index corruption with CREATE INDEX CONCURRENTLY

On Mon, Feb 6, 2017 at 9:47 AM, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> wrote:
>
>
> On Mon, Feb 6, 2017 at 9:41 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>>
>>
>>
>> Hmm. Consider that the first time relcahe invalidation occurs while
>> computing id_attrs, so now the retry logic will compute the correct
>> set of attrs (considering two indexes, if we take the example given by
>> Alvaro above.).
>
>
> I don't quite get that. Since rd_idattr must be already cached at that point
> and we don't expect to process a relcache flush between successive calls to
> RelationGetIndexAttrBitmap(), we should return a consistent copy of
> rd_idattr.
>

Right, I was mistaken. However, I am not sure if there is a need to
perform retry logic in RelationGetIndexAttrBitmap(). It is safe to do
that at transaction end. I feel even though Tom's fix looks reliable
with respect to the problem reported in this thread, we should take
some time and evaluate different proposals and see which one is the
best way to move forward.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com