Bounded, Indeterminate, or a Bug: A Condition-Aware Oracle for Differential Testing of SQL Aggregates
Read the paper · arXiv:2609.00381
What this paper does with SQLancer
SQLancer's oracles are the paper's point of departure: it argues each of the three avoids the case it addresses -- PQS restricting aggregates to a single pivot row, NoREC rewriting predicates, TLP comparing an engine against itself so a consistent rounding error cancels. It also cites two SQLancer papers documenting that floating-point test cases are avoided in practice, and replicates SQLancer's generator to reach the indeterminate regime for SUM.
This paper gives an oracle for differential testing of floating-point SQL aggregates. It argues that treating any cross-engine discrepancy as a bug is unsound for floating point, because non-associativity means engines legitimately disagree, and that the deciding factor is the engine's summation algorithm rather than the query. Ground truth is the exact rational value of the stored doubles, each discrepancy is classified exact, bounded or indeterminate, and a testability boundary is derived beyond which rounding cannot be separated from a bug.
How it was classified
uses infrastructure — uncertain (generator)
M5 says the only route to SUM's indeterminate regime is fuzzer data, replicating SQLancer's generator. Replicating a generator is not necessarily running its code, and no mention settles which.
The only route tosum’s indeterminate regime is fuzzer data: replicating SQLancer’s generator, exactly cancelling ±MAX drives κ≈10306, and the fraction of undecidable columns is non-monotone in n(peaking near20%at n=1000).
extends technique — no
No technique is extended; the citation is background.
compares with — no
No empirical comparison against SQLancer is reported in the mentions.
describes as state of the art — no
The citation does not characterise SQLancer as the state of the art.
Every place it refers to SQLancer (7)
7 sentences, each stored verbatim from the extracted text with where it was found and how. “Citation marker” means the sentence names no tool at all and was reached through a reference number that resolved to a SQLancer publication.
| Id | Sentence | Found by | Where |
|---|---|---|---|
| M1 | Zhang and Rigger [2025] report that constant folding over floating-point values “can result in false alarms, which are avoided in practice by eschewing test cases with small or large floating-point values. |
author year citation |
1 Introduction page 1 |
| M2 | ” Zhong and Rigger [2024] document that DuckDB’s own harness treats two floats as matching when they differ by less than1%. |
author year citation |
1 Introduction page 1 |
| M3 | The oracles of Rigger and Su [2020b,a,c] either restrict aggregates to a single pivot row, target predicates ∗madhulatha@samyama. |
author year citation |
1 Introduction page 1 |
| M4 | DB] 18 Jul 2026 rather than aggregation, or compare an engine againstitselfby query partitioning, so a consistent rounding error cancels and is never observed. |
technique |
1 Introduction page 1 |
| M5 | The only route tosum’s indeterminate regime is fuzzer data: replicating SQLancer’s generator, exactly cancelling ±MAX drives κ≈10306, and the fraction of undecidable columns is non-monotone in n(peaking near20%at n=1000). |
name |
5 Results I: SUM is the linear baseline page 5 |
| M6 | Rigger and Su [2020b] verify a single pivot row, which restricts multi-row aggregates; Rigger and Su [2020a] rewrites predicates; Rigger and Su [2020c] partitions a query against the same engine, so a consistent rounding error cancels rather than being detected. |
author year citation |
7 Results III: real data versus its representation page 11 |
| M7 | Zhang and Rigger [2025] avoid floating-point test cases explicitly; Zhong and Rigger [2024] record the1%epsilon used in practice; Jiang et al. |
author year citation |
7 Results III: real data versus its representation page 11 |