Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

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