On 02/06/2017 01:11 AM, Peter Geoghegan wrote:
> On Sun, Feb 5, 2017 at 4:09 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> 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.
>
> +1. The fact that it wasn't driven by a user report convinces me
> that this is the way to go.
>
+1 to not rushing fixes into releases. While I think we now finally
understand the mechanics of this bug, the fact that we came up with
three different fixes in this thread, only to discover issues with each
of them, warrants some caution.
OTOH I disagree with the notion that bugs that are not driven by user
reports are somehow less severe. Some data corruption bugs cause quite
visible breakage - segfaults, immediate crashes, etc. Those are pretty
clear bugs, and are reported by users.
Other data corruption bugs are much more subtle - for example this bug
may lead to incorrect results to some queries, failing to detect values
violating UNIQUE constraints, issues with foreign keys, etc.
It's damn impossible to notice incorrect query results that only affect
tiny subset of the rows (e.g. rows updated when the CIC was running),
especially when the issue may go away after a while due to additional
non-HOT updates.
Regarding the other symptoms - I wonder how many strange 'duplicate
value' errors were misdiagnosed, wrongly attributed to a recent power
outage, etc.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
