The same database query. The same data. Different totals.
That is the finding Radim Marek published this week. It is not a new kind of problem.
It is a very old one, dressed in fresh clothes. Marek’s analysis, titled “Same rows, different SUM,” walks through why this happens. The culprit is floating-point arithmetic, the IEEE 754 standard nearly every computer uses.
Marek gives the textbook example: 0.1 plus 0.2 does not equal 0.3. The computer gets close, but not exact.
That is not a bug. It is a feature of the standard. The twist Marek documents is about order.
Floating-point addition is not associative. (a + b) + c can differ from a + (b + c) when fractions are involved. A query that sums a column of numbers returns one value when sorted by one column and a different value when sorted by another. Same rows.
Different sum. This echoes older disasters.
In 1991, a Patriot missile battery failed to intercept an incoming Scud because a floating-point timing error accumulated over 100 hours of operation. The error was 0.34 seconds. The Scud killed 28 Americans.
The Army had known about the timing drift. They considered it negligible.
In 1996, the Ariane 5 rocket exploded 40 seconds after liftoff. A 64-bit floating-point number was converted to a 16-bit signed integer. The number was too large.
The guidance system shut down. The rocket veered and broke apart. The cost was $370 million.
Marek’s examples are less dramatic. He is not writing about missiles or rockets.
He is writing about database queries that produce different totals depending on sort order. But the root cause is the same. A quiet assumption that computers do math the way humans do.
The old warning about storing money as a double-precision number is so well drilled, Marek notes, that it has stopped being interesting. Everyone knows that.
The real problem, he says, starts elsewhere. In the quieter corners. In the places where developers think they have accounted for floating-point issues but remain vulnerable.
Marek demonstrates this with test cases. A query returns one total when sorted by one column. The same query returns a different total when sorted by another column.
The data is identical. The query is identical.
Only the processing order changes. This is the part that catches people. The part that looks safe.
The part that is not. Early findings suggest many developers remain exposed.
They know not to store money as a float. They know about rounding errors. They do not know that the order of addition changes the result.
They do not know that sorting can change the sum. The IEEE 754 standard is not going away. It is fundamental to how computers work.
The problem is not the standard. The problem is forgetting that the standard exists.
That it has rules. That those rules produce surprises. Marek does not offer a magic fix.
He offers examples. Concrete ones.
He shows where the trap is. He does not claim to have disarmed it.
