-
Notifications
You must be signed in to change notification settings - Fork 4k
sql/hints: address minor nits #157041
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
sql/hints: address minor nits #157041
Conversation
Release note: None
This might be interesting for testing the scenario when the hints cache is disabled (which is allowed by the cluster setting). Release note: None
b03b4d3 to
8d661d4
Compare
|
The last commit seemingly adds a failure under stress that I don't fully understand: Where does the extra DB read come from given that we're not actually executing any queries that would match the fingerprints? |
DrewKimball
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.
@DrewKimball reviewed 1 of 1 files at r1, 1 of 1 files at r2, 3 of 3 files at r3, all commit messages.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @yuzefovich)
Previously, all tests created a separate hints cache that was running side-by-side with the hints cache of the test server. I'm not sure whether there is a reason for it (other than possibly trying to prevent flakes when we start actually using the cache on the main query path), but I don't think it's necessary (e.g. we shouldn't be touching the hints cache for internal queries, and the tests themselves are the only workload that should be affected by the hints cache, and we have full control of that). This commit hooks up all tests to just use the test server's hints cache. One test for verifying that the initial scan populates the existing hints into the cache needed a minor refactor - we now restart the single-node test cluster to simulate the initial scan. Additionally, the LRU test needed hardening if the initial scan is somewhat delayed. What prompted me to look into this is that I was confused why all rangefeed logs (which I enabled temporarily) were being duplicated in tests. It also expands a comment where the behavior wasn't obvious to me. Release note: None
8d661d4 to
dd515ac
Compare
yuzefovich
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.
That flake was due to initial scan being somewhat delayed (so some of our INSERT INTO system.statement_hints queries happened to perform DB reads).
TFTR!
bors r+
Reviewable status:
complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @DrewKimball)
|
Build failed: |
|
unrelated flake bors r+ |
This PR contains a few commits that address a few nits I noticed while reviewing the plan hints.
Epic: None