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
-
Avoid returning stale attribute bitmaps in RelationGetIndexAttrBitmap().
- bcd7b47c2834 9.2.20 landed
- 32c893c8d125 9.3.16 landed
- 5879958e1f82 9.4.11 landed
- e935696f4dcb 9.5.6 landed
- 7fcddbdd031f 9.6.2 landed
- 2aaec65464da 10.0 landed