-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
storage: TestEngineKeyValidate failed #109919
Comments
Failed here with an allocation during cockroach/pkg/storage/engine_key_test.go Lines 304 to 306 in c379a61
@arulajmani, @nvanbenschoten is it possible we introduced an allocation during parsing of the new lock strengths? |
Doesn't look like it. This was probably always flaky, just rarely so. |
Why would we do only 1 run (first arg to |
The expectation was that it would never allocate. I'm unsure where this one allocation is originating. |
I'm unable to reproduce as well. |
It could be any background task, perhaps in the runtime or in the testing package itself.. Averaging over many runs would "erase" this kind of blip. |
I left this running under stress and eventually hit the failure:
Notice that this was not |
108973: roachtest: allow local execution of tests that need gs fixtures r=yuzefovich a=yuzefovich We recently (in a2ba442) skipped running some tests that need gs fixtures when ran not on gce cloud. However, I think it should be ok to run these tests locally too. Epic: None Release note: None 109514: upgrade: retry errors when dialing instances r=ajstorm a=healthy-pod Release note: None Epic: none Closes #108860 110068: sql: change ordering of (re)creating secondary indexes in ALTER PK r=Xiang-Gu a=Xiang-Gu If we alter the primary key on a table with secondary indexes, we will recreate those secondary indexes as well as creating a new unique secondary index on the old primary key column(s). Previously, in the legacy schema changer, we'd create the new unique secondary index first and then recreate all existing secondary indexes. This is different from how declarative schema changer processes ALTER PK, in which the ordering is the opposite. This is not an issue per se; the only time it shows a difference is when you inspect the table after altering PK via, say, `SHOW CREATE t`, where you'd then observe a slightly different ordering of the indexes. This is actually easier to change the legacy schema changer so both schema changer would produce the same ordering of secondary indexes after an ALTER PK. This will help clean several test cases. Epic: None Release note: None 110122: storage: deflake TestEngineKeyValidate r=RaduBerinde a=jbowens Average the allocs across many runs to avoid flakes from a single alloc (perhaps from the runtime or testing package?). Epic: None Fixes #109919. Release note: none Co-authored-by: Yahor Yuzefovich <[email protected]> Co-authored-by: healthy-pod <[email protected]> Co-authored-by: Xiang Gu <[email protected]> Co-authored-by: Jackson Owens <[email protected]>
storage.TestEngineKeyValidate failed with artifacts on master @ d9c137d7883892e354b767b299bd383576d2a542:
Parameters:
TAGS=bazel,gss
,stress=true
Help
See also: How To Investigate a Go Test Failure (internal)
This test on roachdash | Improve this report!
Jira issue: CRDB-31155
The text was updated successfully, but these errors were encountered: