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

  1. Avoid returning stale attribute bitmaps in RelationGetIndexAttrBitmap().