-
Notifications
You must be signed in to change notification settings - Fork 6.3k
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 kBlockCacheTier read when merge-chain base value is in a blob file #12462
Conversation
@ajkr has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
495ee51
to
4022b69
Compare
@ajkr has updated the pull request. You must reimport the pull request before landing. |
4022b69
to
98894cd
Compare
@ajkr has updated the pull request. You must reimport the pull request before landing. |
@ajkr has updated the pull request. You must reimport the pull request before landing. |
@ajkr has updated the pull request. You must reimport the pull request before landing. |
@ajkr has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
@ajkr has updated the pull request. You must reimport the pull request before landing. |
@ajkr has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
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 so much for the fix (or rather, fixes) @ajkr! LGTM 👍👍
One thing I'm wondering about if there are more issues related to kBlockCacheTier
reads in general - for one, there still seems to be a case in TableCache::MultiGet
where an incomplete status is apparently swallowed and turned into OK.
Thanks for the review! Good point, we should add more kBlockCacheTier testing for other kinds of reads. These findings (this and #12443) simply came from using kBlockCacheTier for max_successive_merges, which only does single-key point lookup. |
@@ -186,7 +186,10 @@ Status CuckooTableReader::Get(const ReadOptions& /*readOptions*/, | |||
return s; | |||
} | |||
bool dont_care __attribute__((__unused__)); | |||
get_context->SaveValue(found_ikey, value, &dont_care); | |||
get_context->SaveValue(found_ikey, value, &dont_care, &s); |
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.
Should we check the return value from SaveValue()
?
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.
I haven't thought about it. Do you have an explanation of what can go wrong without it and/or proposal of what to do with it?
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.
I think we should check the return value as is done in the vicinity of this code.
@@ -610,8 +610,13 @@ void replayGetContextLog(const Slice& replay_log, const Slice& user_key, | |||
|
|||
(void)ret; | |||
|
|||
get_context->SaveValue(ikey, value, &dont_care, value_pinner); | |||
Status read_status; | |||
get_context->SaveValue(ikey, value, &dont_care, &read_status, value_pinner); |
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.
Should we check the return value from SaveValue() ?
The original goal is to propagate failures from
GetContext::SaveValue()
->GetContext::GetBlobValue()
->BlobFetcher::FetchBlob()
up to the user. This call sequence happens when a merge chain ends with a base value in a blob file.There's also fixes for bugs encountered along the way where non-ok statuses were ignored/overwritten, and a bit of plumbing work for functions that had no capability to return a status.
Test Plan:
A repro command
It used to fail like: