-
Notifications
You must be signed in to change notification settings - Fork 3.7k
[bugfix](RowsetIterator) use valid stats when creating segment iterator #21512
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
Conversation
|
run buildall |
|
clang-tidy review says "All clean, LGTM! 👍" |
Tanya-W
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
|
PR approved by anyone and no changes requested. |
e5a96ba to
64804df
Compare
|
run buildall |
|
clang-tidy review says "All clean, LGTM! 👍" |
1 similar comment
|
clang-tidy review says "All clean, LGTM! 👍" |
morningman
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
|
PR approved by at least one committer and no changes requested. |
dataroaring
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Proposed changes
The former logic would directly use read_context as segment iterator's _context

_context = read_context;. But if it's invoked by schema change or compaction, it would pass one read_context whose stats is nullptr like the following picture.Thus the following file cache statistics assignation would get one invalid address
_read_options.io_ctx.file_cache_stats = &read_context->stats->file_cache_stats;which would be the offset for file_cache_stats in stats.This pr would make the read_context->stats always valid to prevent such coredump.
Further comments
If this is a relatively large or complex change, kick off the discussion at dev@doris.apache.org by explaining why you chose the solution you did and what alternatives you considered, etc...