-
Notifications
You must be signed in to change notification settings - Fork 455
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Temporal filters have an off-by-one error #27059
Labels
C-bug
Category: something is broken
Comments
5 tasks
We'll get back to this later. Or maybe it could be considered as part of #27001, where more general occurrences of this problem are being discussed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: