Re: Index corruption with CREATE INDEX CONCURRENTLY

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Pavan Deolasee <pavan.deolasee@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-02-06T02:47:59Z
Lists: pgsql-hackers
On 2017-02-06 08:08:01 +0530, Amit Kapila wrote:
> I don't see in your patch that you are setting rd_bitmapsvalid to 0.

IIRC a plain relcache rebuild should do that (note there's also no place
that directly resets rd_indexattrs).


> Also, I think this suffers from the same problem as the patch proposed
> by Alvaro which is that different attrs (hot_attrs, key_attrs and
> id_attrs) will get computed based on different index lists which can
> cause a problem as mentioned in my mail up thread.

I'm not convinced that that's a legitimate concern.  If that's an issue
with CIC, then we have a lot bigger problems, because relcache entries
and such will be inconsistent anyway if you have non-exclusive locks
while changing catalog data.  In the situations where that happens it
better be harmless (otherwis CiC is broken), and the next access will
recompute them.


> I am not sure but I think your solution can be
> extended to make it somewhat similar to what we do with rd_indexvalid
> (basically, we should set rd_bitmapsvalid to 2 (bitmap is temporarily
> forced) at rel cache invalidation and then clean it up transaction
> end).  I can try something on those lines.

Not sure I understand what you mean with "clean it up at transaction end"?

Greetings,

Andres Freund


Commits

  1. Avoid returning stale attribute bitmaps in RelationGetIndexAttrBitmap().