Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY |
Дата | |
Msg-id | 20170206024759.sxq35elmy7tmxatc@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY (Amit Kapila <amit.kapila16@gmail.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: