-
Notifications
You must be signed in to change notification settings - Fork 467
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
Add a particular test case for HGETALL with async_io=true #1401
Add a particular test case for HGETALL with async_io=true #1401
Conversation
Was reproducible with RocksDB v8.0.0, large values in a hash set (>512 bytes). After the COMPACT command was executed, HGETALL/HVALS/HKEYS couldn't "see" all the elements of the hash set. However, HGET could find those values. It looked like the iterator via the snapshot didn't see them for some reason. Since the version of the RocksDB was bumped to v8.0.1, the bug disappeared.
@torwig thanks for help in discovering this bug |
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
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.
Thank you!
|
||
require.NoError(t, rdb.Do(ctx, "COMPACT").Err()) | ||
|
||
time.Sleep(5 * time.Second) |
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.
Is it possible to be unstable?
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.
What do you mean by unstable
? Since the COMPACT
command is asynchronous, I add the time.Sleep
call here.
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.
Thanks for your explanation :)
Generally, sleep is unpredictable, so it may sleep too short and miss the correct condition. I asked here for more background. If we cannot have a determinate latch for COMPACT completion, I'm OK with current way.
Ooops, not the correct branch. I'll re-push now. |
Now it's OK. |
Thanks all, merging... |
The bug was reproducible with RocksDB v8.0.0, large values in a hash set (>512 bytes).
After the COMPACT command was executed, HGETALL/HVALS/HKEYS couldn't "see" all the elements of the hash set. However, HGET could find those values.
It looked like the iterator via the snapshot didn't see them for some reason.
Since the version of the RocksDB was bumped to v8.0.1, the bug disappeared.
Adding the test case to prevent facing this bug in the future.
This is the output of the failed test: