On Sun, Feb 5, 2017 at 1:34 PM, Martín Marqués <martin@2ndquadrant.com> wrote:
> El 05/02/17 a las 10:03, Michael Paquier escribió:
>> On Sun, Feb 5, 2017 at 6:53 PM, Pavel Stehule <pavel.stehule@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.
>
> The fact that the bug has been around for a long time doesn't mean we
> shouldn't take it seriously.
>
> IMO any kind of corruption (heap or index) should be prioritized.
> There's also been comments about maybe this being the cause of old
> reports about index corruption.
>
> I ask myself if it's a good idea to make a point release with a know
> corruption bug in it.
I don't think this kind of black-and-white thinking is very helpful.
Obviously, data corruption is bad. However, this bug has (from what
one can tell from this thread) been with us for over a decade; it must
necessarily be either low-probability or low-severity, or somebody
would've found it and fixed it before now. Indeed, the discovery of
this bug was driven by new feature development, not a user report. It
seems pretty clear that if we try to patch this and get it wrong, the
effects of our mistake could easily be a lot more serious than the
original bug.
Now, I do not object to patching this tomorrow before the wrap if the
various senior hackers who have studied this (Tom, Alvaro, Pavan,
Amit) are all in agreement on the way forward. But if there is any
significant chance that we don't fully understand this issue and that
our fix might cause bigger problems, it would be more prudent to wait.
I'm all in favor of releasing important bug fixes quickly, but
releasing a bug fix before we're sure we've fixed the bug correctly is
taking a good principle to an irrational extreme.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company