Re: Index corruption with CREATE INDEX CONCURRENTLY
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pavan Deolasee <pavan.deolasee@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-02-06T12:13:46Z
Lists: pgsql-hackers
Tom Lane wrote: > Pavan Deolasee <pavan.deolasee@gmail.com> writes: > > 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. The way to deal with that without > looping is to test whether the index set *actually* changed, not whether > it just might have changed. Ah, that's a nice and simple way to fix that patch! I see that Pavan confirmed that it fixes the tests we saw failing too. It seems to me that we should go with this one, and it looks unlikely that this causes other problems. BTW, while neiter Pavan nor I sent this patch to -hackers, this implementation is pretty much the same thing we did. Pavan deserves credit as co-author in this commit. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, 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