Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY
Date
Msg-id CAA4eK1Lj=QrDEGb5M=K79DRj6KGzZX6uub3jkqjxNgfP7UdM5g@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY  (Pavan Deolasee <pavan.deolasee@gmail.com>)
List pgsql-hackers
On Mon, Feb 6, 2017 at 9:47 AM, Pavan Deolasee <pavan.deolasee@gmail.com> wrote:
>
>
> On Mon, Feb 6, 2017 at 9:41 AM, Amit Kapila <amit.kapila16@gmail.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] 0/NULL/NIL assignments in build_*_rel()
Next
From: David Fetter
Date:
Subject: Re: [HACKERS] 3D Z-curve spatial index