Repository navigation
fix: saturate LimitPushPastWindows and ROWS frame bounds for huge FOLLOWING - #26674
Open
ninglinLiu wants to merge 1 commit into
Open
ninglinLiu wants to merge 1 commit into
ninglinLiu wants to merge 1 commit into
Conversation
…LOWING Closes apache#26658. A ROWS FOLLOWING bound of u64::MAX made LimitPushPastWindows panic in debug (and wrap the TopK fetch in release) when growing fetch by lookahead. Use saturating_add like EnsureRequirements sort pushdown, and saturate the matching ROWS range arithmetic in window_state so the query can still execute.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Important
Fork CI setup: For pull requests from a fork to
main, enable workflows in your fork's Actions tab before you push.See the fork CI setup guide.
Which issue does this PR close?
LimitPushPastWindowspanics with "attempt to add with overflow" for a largeROWS ... FOLLOWINGbound #26658.Rationale for this change
A window frame with a huge
ROWS ... FOLLOWINGbound (e.g.u64::MAX) madeLimitPushPastWindowspanic in debug builds when growingfetchbylookahead(fetch + ctx.lookahead). In release builds the same addition wraps, so theSortExecTopK fetch can become smaller than the query needs.EnsureRequirementssort pushdown already usessaturating_addfor the same kind of sum.Running the issue's reproduction also hit overflow in
calculate_range_rows(idx + n as usize + 1), so the ROWS frame bound math is saturated the same way so the query can finish.What changes are included in this PR?
saturating_addinLimitPushPastWindowswhen combining fetch/lookahead/skip (and when accumulating lookahead).Followingstart/end index arithmetic inwindow_state::calculate_range_rows.window_limits.sltcase for the issue reproduction.What is the testing strategy for this PR?
datafusion/sqllogictest/test_files/window_limits.sltcovering the issue query.cargo test --test sqllogictests -- window_limits.Are there any user-facing changes?
Bug fix only: queries with extremely large ROWS FOLLOWING bounds no longer panic in the optimizer / ROWS frame path. No API change.