On 02/06/2017 01:11 AM, Peter Geoghegan wrote:
On Sun, Feb 5, 2017 at 4:09 PM, Robert Haas <robertmh...@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
Regarding the other symptoms - I wonder how many strange 'duplicate
value' errors were misdiagnosed, wrongly attributed to a recent power
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: