Skip to content

Fix fast-path plan creation to be mindful of the finishing's offset#36044

Open
ggevay wants to merge 1 commit intoMaterializeInc:mainfrom
ggevay:fix-fast-path-finishing-offset
Open

Fix fast-path plan creation to be mindful of the finishing's offset#36044
ggevay wants to merge 1 commit intoMaterializeInc:mainfrom
ggevay:fix-fast-path-finishing-offset

Conversation

@ggevay
Copy link
Copy Markdown
Contributor

@ggevay ggevay commented Apr 13, 2026

@ggevay ggevay added the A-ADAPTER Topics related to the ADAPTER layer label Apr 13, 2026
@github-actions
Copy link
Copy Markdown
Contributor

Thanks for opening this PR! Here are a few tips to help make the review process smooth for everyone.

PR title guidelines

  • Use imperative mood: "Fix X" not "Fixed X" or "Fixes X"
  • Be specific: "Fix panic in catalog sync when controller restarts" not "Fix bug" or "Update catalog code"
  • Prefix with area if helpful: compute: , storage: , adapter: , sql:

Pre-merge checklist

  • The PR title is descriptive and will make sense in the git log.
  • This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
  • If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.
  • This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
  • If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
  • If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).

@ggevay ggevay force-pushed the fix-fast-path-finishing-offset branch from 96961ce to bbcdeb9 Compare April 13, 2026 14:50
@ggevay ggevay marked this pull request as ready for review April 13, 2026 15:03
@ggevay ggevay requested a review from a team as a code owner April 13, 2026 15:03
@ggevay ggevay requested a review from mtabebe April 13, 2026 15:03
Comment on lines +475 to +477
i128::cast_from(l)
>= i128::cast_from(*finishing_limit)
+ i128::cast_from(finishing.offset)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the benefit of using u128 over finishing_limit.saturating_add(finishing.offset)?

Copy link
Copy Markdown
Contributor Author

@ggevay ggevay Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If l is exactly equal to i64::max, then the saturating_add capping the right-hand side down to also i64::max could result in a false positive detection, no? (I think this bug couldn't actually manifest, because our Diff type is also i64, but we better not rely on that here.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-ADAPTER Topics related to the ADAPTER layer

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants