Yaoxuan Wu created FLINK-40929:
----------------------------------
Summary: SUM on DECIMAL silently returns a wrong, order-dependent
value after an overflow
Key: FLINK-40929
URL: https://issues.apache.org/jira/browse/FLINK-40929
Project: Flink
Issue Type: Bug
Components: Table SQL / Runtime
Affects Versions: 2.3.0
Reporter: Yaoxuan Wu
When a DECIMAL SUM overflows, Flink neither raises an error nor returns NULL.
It returns a regular, non-NULL value that is the sum of only the rows after the
overflow, so the result is wrong and depends on the row order.
{code:java}
SET 'parallelism.default' = '1';
SELECT SUM(x) FROM (VALUES
(CAST('99999999999999999999999999999999999999' AS DECIMAL(38, 0))),
(CAST(1 AS DECIMAL(38, 0))), (CAST(2 AS DECIMAL(38, 0))), (CAST(3 AS
DECIMAL(38, 0)))
) AS v(x);
-- returns 5 (= 2 + 3) {code}
Same values, different order (max = 10^38 - 1):
||nput order||SUM||
|max, 1, 2, 3|5|
|max, 705, 901|901|
|705, max, 901|901|
|705, 901, max|NULL|
With parallelism > 1 the order, and therefore the result, depends on the
partitioning. By contrast, a row-level {{x + 1}} on the same value raises an
error.
Cause: {{SumAggFunction}} accumulates with {{isNull(sum) ? operand : sum +
operand}} (likewise in {{{}mergeExpressions{}}}). The DECIMAL {{+}} returns
NULL on overflow, so the overflowed sum is mistaken for "no value yet" and the
next row restarts it.
Expected: once the sum overflows, the result should stay NULL (or raise an
error, as row-level arithmetic does), independent of the row order.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
