-
Notifications
You must be signed in to change notification settings - Fork 312
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
fix: full_scan
can't scan data completely in some occassions
#825
Conversation
Which client version when encounter the bug? Maybe you can see the replay and make sure if the problem has fixed: |
I don't think it's the root cause of the bug. You can fix c++ client by XiaoMi/pegasus-java-client#156 |
full_scan
can't scan data completely in some occassions
Could you format your code? Otherwise, it can't pass the CI. |
src/server/pegasus_server_impl.cpp
Outdated
rd_opts.total_order_seek = true; | ||
rd_opts.prefix_same_as_start = false; | ||
} | ||
if (_data_cf_opts.prefix_extractor && request.full_scan) { |
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.
This will leads to compatibility issues. For example, if old version client calls new version server(which use request.full_scan to judge whether it is full scan), the full_scan
will always be false in request. And full scan can't works well in this situation.
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.
ok, wait me to change a little
LGTM |
What problem does this PR solve?
#824
What is changed and how does it work?
The previous server-side on_get_scanners function judged whether it is full_scan or non-full_scan by whether the start_key in the request structure is filled with hash_key, which will cause a bug in the issue; the way to fix here is to directly add a field to the request structure to determine
Test
manual test