-
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
build: add roachtests to be run on every PR #25297
Conversation
Yay! I'll let @benesch comment on the scripting. Adding Review status: 0 of 4 files reviewed at latest revision, all discussions resolved, some commit checks failed. Comments from Reviewable |
Updated the builder image and switched this proof of concept to kv/splits |
though @benesch should still give this a look as I'm not familiar with how all the teamcity scripts fit together. Review status: 0 of 4 files reviewed at latest revision, all discussions resolved, some commit checks failed. Comments from Reviewable |
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.
LGTM modulo removing the modifications to teamcity-test and teamcity-assert-clean!
Release note: None
bors r=benesch,petermattis |
👎 Rejected by label |
bors r=benesch,petermattis |
25297: build: add roachtests to be run on every PR r=benesch,petermattis a=danhhz Release note: None 25434: opt: Change how Any operator is represented and flattened r=andy-kimball a=andy-kimball The Any operator currently takes a single input rowset, and expects it to return a single boolean column. The hoister flattens the Any operator by testing and projecting that boolean column. The problem is that this representation cannot easily be decorrelated. Example: z = ANY(SELECT x FROM xy) This is currently represented as: (Any (Project xy [ z=x ])) The z=x projection field cannot easily be hoisted over a left join. This commit uses an alternate representation: (Any xy z EqOp) The new representation keeps the input, scalar, and comparison op components separate, so they can be combined in ways that it easier to decorrelate. 25456: storage: fix deadlock in consistency queue r=bdarnell,a-robinson a=tschottdorf When `CheckConsistency` returns an error, the queue checks whether the store is draining to decide whether the error is worth logging. Unfortunately this check was incorrect and would block until the store actually started draining. A toy example of this problem is below (this will deadlock). The dual return form of chan receive isn't non-blocking -- the second parameter indicates whether the received value corresponds to a closing of the channel. Switch to a `select` instead. ```go package main import ( "fmt" ) func main() { ch := make(chan struct{}) _, ok := <-ch fmt.Println(ok) } ``` Touches #21824. Release note (bug fix): Prevent the consistency checker from deadlocking. This would previously manifest itself as a steady number of replicas queued for consistency checking on one or more nodes and would resolve by restarting the affected nodes. Co-authored-by: Daniel Harrison <[email protected]> Co-authored-by: Andrew Kimball <[email protected]> Co-authored-by: Tobias Schottdorf <[email protected]>
Build succeeded |
Unless someone objects, I'm going to wait until I'm back in the office on Wednesday to actually hook this up to Teamcity. |
Release note: None