-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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/opt/exec/execbuilder: TestExecBuild failed #50863
Comments
I can't figure out what the actual failure was here. Logs say
but there is nothing like that in the artifacts for the build. I tried to reproduce, no luck so far (though I hit #51027, I'll try again when that is fixed). |
(sql/opt/exec/execbuilder).TestExecBuild failed on master@e9a4f83e3eee59510f97db2c6e0df9b57cf6b944:
MoreParameters:
See this test on roachdash |
(sql/opt/exec/execbuilder).TestExecBuild failed on master@dafb69aa4af50d965698738323680c9175d59511:
MoreParameters:
See this test on roachdash |
This commit fixes a race condition that was introduced in cockroachdb#51616. The race condition existed because it was possible for two refreshes to be triggered in close succession, and there was no mechanism to prevent the first refresh from overwriting the second if it was delayed. We fix the race condition by introducing two boolean flags into each cache entry: refreshing and mustRefreshAgain. If refreshing is true, that indicates that the current statistics for this table are stale, and we are in the process of fetching the updated stats from the database. In the mean time, other callers can use the stale stats and do not need to wait. If a goroutine tries to perform a refresh when a refresh is already in progress, it will see that refreshing=true and will set the mustRefreshAgain flag to true before returning. When the original goroutine that was performing the refresh returns from the database and sees that mustRefreshAgain=true, it will trigger another refresh. Informs cockroachdb#50863 Release note: None
51691: kvserver: remove ToIsLearner flag from RaftHeartbeat r=yuzefovich a=nvanbenschoten This commit removes the ToIsLearner flag from the RaftHeartbeat message. This is allowed because 20.2 no longer need to deal with preemptive snapshots. This completes @ajwerner's heroic migration started in 99a031d and followed up by b2850e1. 51692: tree: cast TIMESTAMP to TEXT without timezone data r=rohany,adityamaru a=otan This better matches postgres. I'm guessing it used to be done this way to match the CLI output (which we can't fix without changing lib/pq), but this affects output results from ORM tests. Note that CLI output is not affected unless TIMESTAMP is cast to text. Release note (sql change): Casting TIMESTAMP types to TEXT related types now omits the timezone component. For example, '2001-12-15 15:14:13'::TIMESTAMP will now format as '2001-12-15 15:14:13' instead of '2001-12-15 15:14:13+00:00'. 51770: cmd/skipped-tests: utility to post skipped tests to slack r=yuzefovich a=petermattis Release note: None 51773: sql: panic with assertion errors, not raw strings r=jordanlewis a=jordanlewis Panicking with raw strings will cause the strings to be redacted. Release note: None 51780: opt: fix flake in TestExecBuild due to new stats cache refresh mechanism r=rytaft a=rytaft This commit fixes a flake caused by the new stats cache update mechanism, which refreshes the stats asynchronously. The solution is to retry the test query until the new stats are available in the cache. Fixes #50863 Release note: None 51784: sql: disable distribution of plans when transaction has modified a type r=rohany a=rohany Fixes #50897. Release note (sql change): Transactions that have modified or created a type will execute queries on the local node, rather than distributing the queries to other nodes in the cluster. 51806: roachtest: deflake disk-stalled roachtests r=irfansharif a=irfansharif Fixes #51724, which failed with the salient error: ERROR: no --join flags provided to 'cockroach start' Since this test is spinning up a single node cluster to test disk stalls, it suffices to use start-single-node instead. Release note: None Co-authored-by: Nathan VanBenschoten <[email protected]> Co-authored-by: Oliver Tan <[email protected]> Co-authored-by: Peter Mattis <[email protected]> Co-authored-by: Jordan Lewis <[email protected]> Co-authored-by: Rebecca Taft <[email protected]> Co-authored-by: Rohan Yadav <[email protected]> Co-authored-by: irfan sharif <[email protected]>
This commit fixes a race condition that was introduced in cockroachdb#51616. The race condition existed because it was possible for two refreshes to be triggered in close succession, and there was no mechanism to prevent the first refresh from overwriting the second if it was delayed. We fix the race condition by introducing two boolean flags into each cache entry: refreshing and mustRefreshAgain. If refreshing is true, that indicates that the current statistics for this table are stale, and we are in the process of fetching the updated stats from the database. In the mean time, other callers can use the stale stats and do not need to wait. If a goroutine tries to perform a refresh when a refresh is already in progress, it will see that refreshing=true and will set the mustRefreshAgain flag to true before returning. When the original goroutine that was performing the refresh returns from the database and sees that mustRefreshAgain=true, it will trigger another refresh. Informs cockroachdb#50863 Release note: None
This commit fixes a race condition that was introduced in cockroachdb#51616. The race condition existed because it was possible for two refreshes to be triggered in close succession, and there was no mechanism to prevent the first refresh from overwriting the second if it was delayed. We fix the race condition by introducing two boolean flags into each cache entry: refreshing and mustRefreshAgain. If refreshing is true, that indicates that the current statistics for this table are stale, and we are in the process of fetching the updated stats from the database. In the mean time, other callers can use the stale stats and do not need to wait. If a goroutine tries to perform a refresh when a refresh is already in progress, it will see that refreshing=true and will set the mustRefreshAgain flag to true before returning. When the original goroutine that was performing the refresh returns from the database and sees that mustRefreshAgain=true, it will trigger another refresh. Informs cockroachdb#50863 Release note: None
51805: stats: fix race condition when refreshing cache r=rytaft a=rytaft This commit fixes a race condition that was introduced in #51616. The race condition existed because it was possible for two refreshes to be triggered in close succession, and there was no mechanism to prevent the first refresh from overwriting the second if it was delayed. We fix the race condition by introducing two boolean flags into each cache entry: `refreshing` and `mustRefreshAgain`. If `refreshing` is true, that indicates that the current statistics for this table are stale, and we are in the process of fetching the updated stats from the database. In the mean time, other callers can use the stale stats and do not need to wait. If a goroutine tries to perform a refresh when a refresh is already in progress, it will see that `refreshing=true` and will set the `mustRefreshAgain` flag to `true` before returning. When the original goroutine that was performing the refresh returns from the database and sees that `mustRefreshAgain=true`, it will trigger another refresh. Informs #50863 Release note: None Co-authored-by: Rebecca Taft <[email protected]>
This commit fixes a flake caused by the new stats cache update mechanism, which refreshes the stats asynchronously. The solution is to retry the test query until the new stats are available in the cache. Fixes cockroachdb#50863 Release note: None
This commit fixes a race condition that was introduced in cockroachdb#51616. The race condition existed because it was possible for two refreshes to be triggered in close succession, and there was no mechanism to prevent the first refresh from overwriting the second if it was delayed. We fix the race condition by introducing two boolean flags into each cache entry: refreshing and mustRefreshAgain. If refreshing is true, that indicates that the current statistics for this table are stale, and we are in the process of fetching the updated stats from the database. In the mean time, other callers can use the stale stats and do not need to wait. If a goroutine tries to perform a refresh when a refresh is already in progress, it will see that refreshing=true and will set the mustRefreshAgain flag to true before returning. When the original goroutine that was performing the refresh returns from the database and sees that mustRefreshAgain=true, it will trigger another refresh. Informs cockroachdb#50863 Release note: None
This commit fixes a flake caused by the new stats cache update mechanism, which refreshes the stats asynchronously. The solution is to retry the test query until the new stats are available in the cache. Fixes cockroachdb#50863 Release note: None
This commit fixes a race condition that was introduced in cockroachdb#51616. The race condition existed because it was possible for two refreshes to be triggered in close succession, and there was no mechanism to prevent the first refresh from overwriting the second if it was delayed. We fix the race condition by introducing two boolean flags into each cache entry: refreshing and mustRefreshAgain. If refreshing is true, that indicates that the current statistics for this table are stale, and we are in the process of fetching the updated stats from the database. In the mean time, other callers can use the stale stats and do not need to wait. If a goroutine tries to perform a refresh when a refresh is already in progress, it will see that refreshing=true and will set the mustRefreshAgain flag to true before returning. When the original goroutine that was performing the refresh returns from the database and sees that mustRefreshAgain=true, it will trigger another refresh. Informs cockroachdb#50863 Release note: None
(sql/opt/exec/execbuilder).TestExecBuild failed on master@84c0a3e960421ec754583daa708c8c3542b4f1e3:
More
Parameters:
See this test on roachdash
powered by pkg/cmd/internal/issues
The text was updated successfully, but these errors were encountered: