rowexec: fix TestUncertaintyErrorIsReturned under race #108328
Conversation
Release note: None
We just saw a case when `TestUncertaintyErrorIsReturned` failed under race because we got a different DistSQL plan. This seems plausible in case the range cache population (which the test does explicitly) isn't quick enough for some reason, so this commit allows for the DistSQL plan to match the expectation via `SucceedsSoon` (if we happen to get a bad plan, then the following query execution should have the up-to-date range cache). Release note: None
|
This change is |
yuzefovich
requested review from
msirek and
DrewKimball
and removed request for
msirek
There was a problem hiding this comment.
Reviewed 18 of 18 files at r1, 1 of 1 files at r2, all commit messages.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @DrewKimball and @yuzefovich)
pkg/sql/rowexec/processors_test.go line 761 at r2 (raw file):
// time in case the range cache wasn't populated as we // expected (we've seen this under race in #108250). testutils.SucceedsSoon(t, func() error {
Is there anyway to force an update to the range cache before making this query? I'm of the opinion that retries in tests are generally a bad thing because they make tests slower and tests that use them can still flake. I know we use retries everywhere, and we don't have to stop using them with this PR, but I'd love to see us using less and less retries in tests over the long-term.
There was a problem hiding this comment.
TFTR!
bors r+
Reviewable status:
pkg/sql/rowexec/processors_test.go line 761 at r2 (raw file):
Previously, mgartner (Marcus Gartner) wrote…
Is there anyway to force an update to the range cache before making this query? I'm of the opinion that retries in tests are generally a bad thing because they make tests slower and tests that use them can still flake. I know we use retries everywhere, and we don't have to stop using them with this PR, but I'd love to see us using less and less retries in tests over the long-term.
I don't think there is an explicit way directly on the rangecache.RangeCache object to do that, but the test already uses the implicit way (performing SELECT query) in populateRangeCacheAndDisableBuffering. I'm not sure why it's insufficient, perhaps the implicit way is too slow under race. I agree that we should be conscious about putting retries in place, but it seems to me that here it's reasonable.
|
This PR was included in a batch that timed out, it will be automatically retried |
|
Build failed (retrying...): |
|
Build succeeded: |
We just saw a case when
TestUncertaintyErrorIsReturnedfailed under race because we got a different DistSQL plan. This seems plausible in case the range cache population (which the test does explicitly) isn't quick enough for some reason, so this commit allows for the DistSQL plan to match the expectation viaSucceedsSoon(if we happen to get a bad plan, then the following query execution should have the up-to-date range cache).Fixes: #108250.
Release note: None