Re: Index corruption with CREATE INDEX CONCURRENTLY
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Keith Fiske <keith@omniti.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Pavan Deolasee <pavan.deolasee@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-02-17T16:12:45Z
Lists: pgsql-hackers
Keith Fiske wrote: > Was just curious if anyone was able to come up with any sort of method to > test whether an index was corrupted by this bug, other than just waiting > for bad query results? We've used concurrent index rebuilding quite > extensively over the years to remove bloat from busy systems, but > reindexing the entire database "just in case" is unrealistic in many of our > cases. As stated, if the CREATE INDEX operates on columns that are previously already indexed (which is normally the case when you rebuild because of bloat) then there is no chance of index corruption. Scanning indexes+tables is just as load-intensive as rebuilding the indexes anyway. You don't save any work. I suppose it can be a problem if you have an index big enough that it doesn't fit on your remaining free space (but in that case you have a pre-existing problem which you should solve anyway). -- Á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