On Mon, Feb 6, 2017 at 5:44 AM, Andres Freund <and...@anarazel.de> wrote:
> On 2017-02-05 12:51:09 -0500, Tom Lane wrote: > > Michael Paquier <michael.paqu...@gmail.com> writes: > > > On Sun, Feb 5, 2017 at 6:53 PM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > > >> I agree with Pavan - a release with known important bug is not good > idea. > > > > > This bug has been around for some time, so I would recommend taking > > > the time necessary to make the best fix possible, even if it means > > > waiting for the next round of minor releases. > > > > I think the way to think about this sort of thing is, if we had found > > this bug when a release wasn't imminent, would we consider it bad enough > > to justify an unscheduled release cycle? I have to think the answer for > > this one is "probably not". > > +1. I don't think we serve our users by putting out a nontrivial bugfix > hastily. Nor do I think we serve them in this instance by delaying the > release to cover this fix; there's enough other fixes in the release > imo. > > I'm bit a surprised with this position. What do we tell our users now that we know this bug exists? They can't fully trust CIC and they don't have any mechanism to confirm if the newly built index is corruption free or not. I'm not suggesting that we should hastily refactor the code, but at the very least some sort of band-aid fix which helps the situation, yet have minimal side-effects, is warranted. I believe proposed retry patch does exactly that. Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
