Re: Index corruption with CREATE INDEX CONCURRENTLY
Pavan Deolasee <pavan.deolasee@gmail.com>
From: Pavan Deolasee <pavan.deolasee@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-02-06T02:31:57Z
Lists: pgsql-hackers
On Mon, Feb 6, 2017 at 1:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > > 2. In the second patch, we tried to recompute attribute lists if a > relcache > > flush happens in between and index list is invalidated. We've seen > problems > > with that, especially it getting into an infinite loop with > > CACHE_CLOBBER_ALWAYS. Not clear why it happens, but apparently relcache > > flushes keep happening. > > Well, yeah: the point of CLOBBER_CACHE_ALWAYS is to make a relcache flush > happen whenever it possibly could. Ah, ok. That explains why the retry logic as originally proposed was causing infinite loop. > The way to deal with that without > looping is to test whether the index set *actually* changed, not whether > it just might have changed. > I like this approach. I'll run the patch on a build with CACHE_CLOBBER_ALWAYS, but I'm pretty sure it will be ok. I also like the fact that retry logic is now limited to only when index set changes, which fits in the situation we're dealing with. Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
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