Re: Index corruption with CREATE INDEX CONCURRENTLY
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pavan Deolasee <pavan.deolasee@gmail.com>, Michael Paquier <michael.paquier@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-02-06T03:47:24Z
Lists: pgsql-hackers
On 2017-02-05 22:34:34 -0500, Tom Lane wrote: > Pavan Deolasee <pavan.deolasee@gmail.com> writes: > The point is that there's a nontrivial chance of a hasty fix introducing > worse problems than we fix. > > Given the lack of consensus about exactly how to fix this, I'm feeling > like it's a good idea if whatever we come up with gets some time to age > awhile in git before we ship it. Right. And I'm not even convinced that we really know the extent of the bug; it seems fairly plausible that there's further incidences of this. There's also the issue that the mechanics in the older backbranches are different again, because of SnapshotNow. >> I'm bit a surprised with this position. What do we tell our users now that >> we know this bug exists? That we're scheduling a bugfix for the next point release. I don't think we can truthfully claim that there's no known corruption bugs in any of the release in the last few years. 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