-
Notifications
You must be signed in to change notification settings - Fork 3.8k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
73171: spanconfig/sqlwatcher: hide factory pattern, speed up tests, surface no-op checkpoints periodically r=irfansharif a=irfansharif See individual commits. --- **spanconfig/sqlwatcher: speed up tests** Using a more aggressive closed timestamp target duration brings the runtime for TestSQLWatcherReactsToUpdate down from 45s+ to single digits. To speed it up, we also just re-use the same SQLWatcher instead of creating a new one for every test case. Other tests in the package benefit from a similar treatment. Using the default target duration in fact masked a buggy test; in a future commit we end up rewrite that test so it's skipped for now. **spanconfig/sqlwatcher: hide the factory pattern** The only mutable state across concurrent WatchForSQLUpdate calls was the internal buffer, which does not need to hang off the surrounding struct. This obviates the need for the factory pattern we were using -- callers can set up multiple SQLWatchers concurrently as is (see TestSQLWatcherMultiple). This PR first hides the factory under the package boundary; in a later commit it shed it altogether. This has the benefit of reducing the number of symbols in pkg/spanconfig and making it symmetric with the other spanconfig dependencies typically found together (KVAccessor, SQLTranslator). It's also every-so-slightly less verbose to use in the upcoming spanconfig.Reconciler (#71994). **spanconfig/sqlwatcher: checkpoint, even without updates** If `system.{descriptor,zones}` is static, we would previously discard all checkpoint events. This is not what we want -- we'd still like to know how caught up we are, with ongoing updates or otherwise. MVCC GC, after all, can still happen; if our last checkpoint was when the last update occurred, we may end up doing a lot of unnecessary work when finding out our last checkpoint was GC-ed from underneath us. Lack of periodic checkpoints also makes tests difficult to write -- you'd have to induce a benign update to flush out all earlier ones. This latent flakiness was uncovered after speeding up some existing tests in an earlier commit. NB: For incremental (possibly noop) checkpoints, we need to ensure that the sqlwatcher's buffer is initialized with a low watermark. When flushing events, we take the most conservative timestamp. If not initialized to a high water, this might be 0 -- violating the sqlwatcher's monotonically increasing checkpoint ts invariant. Release note: None 73290: sql/schemachanger: remove cycle DepEdge rules, add SameStage kind r=ajwerner a=ajwerner First few commits are mostly minor cleanup. Last commit is the meat of the change. This commit seeks to rectify an early mistake in the architecture of the declarative schema changer. In the original design, we knew we wanted certain transitions to happen in the same stage. In order to deal with that, we created rules that allowed for special types of cycles in dependencies to exist. This was a mistake. Instead, we replace this by a `Kind` property of `DepEdge`s which indicates whether the target pointed to merely needs to `HappenBefore` or whether it also needs to happen in the `SameStage`. This allows us to express exactly what we meant. This change also uncovered some broken cycles which never were intended to exist. The resultant plans generally look better. Release note: None Co-authored-by: irfan sharif <irfanmahmoudsharif@gmail.com> Co-authored-by: Andrew Werner <awerner32@gmail.com>
- Loading branch information
Showing
33 changed files
with
1,486 additions
and
1,055 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.