Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

Looking at the history and some past discussions, it seems Tomas reported somewhat similar problem and Andres proposed a patch here https://www.postgresql.org/message-id/20140514155204.GE23943@awork2.anarazel.de which got committed via b23b0f5588d2e2. Not exactly the same issue, but related to relcache flush happening in index_open().

I wonder if we should just add a recheck logic in RelationGetIndexAttrBitmap() such that if rd_indexvalid is seen as 0 at the end, we go back and start again from RelationGetIndexList(). Or is there any code path that relies on finding the old information?

The following comment at the top of RelationGetIndexAttrBitmap() also seems like a problem to me. CIC works with lower strength lock and hence it can change the set of indexes even though caller is holding the RowExclusiveLock, no? The comment seems to suggest otherwise.