You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We introduced in #14463 an off-by-one error, recorded in temporal.slt:
# We don't currently support specifying the max timestamp due to a limitation in linear.rs and the step_mz_timestamp internal function.
# That big number there should be u64::MAX.
statement ok
CREATE VIEW intervals_max (a, b) AS VALUES (0, 18446744073709551615)
The issue is that rather than perform a += 1 in the space of numerics and then determine if the result fits in a u64, we do the increment in a u64 natively and produce a EvalError::MzTimestampStepOverflow if it overflows. This means that the behavior of selecting from a index and a view can be different if the data contains u64::MAX (the index will error, the view will not).
I think in principle one should be able to guard evaluation in linear.rs with the logic looks for this error specifically and when observed performs the pre-#14463 behavior (which depends on whether it is lower or upper, but largely "ignoring the bound" rather than erroring).
Edit: to reframe, the issue is that there is different behavior with and without an index. Our two evaluation strategies, 1. replace mz_now() by a known timestamp and 2. build a dataflow widget, produce different outputs on some inputs. Those inputs affected are few, as off-by-one errors tend to be, but the difference between the two means has the potential to introduce unknown bad behavior.
The text was updated successfully, but these errors were encountered:
What version of Materialize are you using?
main
What is the issue?
We introduced in #14463 an off-by-one error, recorded in
temporal.slt
:The issue is that rather than perform a
+= 1
in the space ofnumerics
and then determine if the result fits in au64
, we do the increment in au64
natively and produce aEvalError::MzTimestampStepOverflow
if it overflows. This means that the behavior of selecting from a index and a view can be different if the data containsu64::MAX
(the index will error, the view will not).I think in principle one should be able to guard evaluation in
linear.rs
with the logic looks for this error specifically and when observed performs the pre-#14463 behavior (which depends on whether it islower
orupper
, but largely "ignoring the bound" rather than erroring).Edit: to reframe, the issue is that there is different behavior with and without an index. Our two evaluation strategies, 1. replace
mz_now()
by a known timestamp and 2. build a dataflow widget, produce different outputs on some inputs. Those inputs affected are few, as off-by-one errors tend to be, but the difference between the two means has the potential to introduce unknown bad behavior.The text was updated successfully, but these errors were encountered: