-
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
roachtest,sqlinstance: fix multitenant_upgrade test #87111
Merged
Merged
Conversation
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
rafiss
force-pushed
the
fix-multi-tenant-upgrade
branch
from
August 30, 2022 21:35
7e8848a
to
11a6c9c
Compare
ajwerner
approved these changes
Sep 1, 2022
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!
@@ -162,6 +162,7 @@ func (r *Reader) maybeStartRangeFeed(ctx context.Context) *rangefeed.RangeFeed { | |||
updateCacheFn, | |||
rangefeed.WithInitialScan(initialScanDoneFn), | |||
rangefeed.WithOnInitialScanError(initialScanErrFn), | |||
rangefeed.WithRowTimestampInInitialScan(true), |
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.
honestly, this is the problem with functional options :(
rafiss
changed the title
roachtest: fix multitenant_upgrade test
roachtest,sqlinstance: fix multitenant_upgrade test
Sep 1, 2022
The tenant must be initialized by a system tenant using an old binary in order to be running on an old binary itself. Also, we no longer finalize the secondary tenant upgrade before finalizing the system tenant upgrade. Release note: None Release justification: test only change
Previously, the sql instance cache would be populated using the timestamp of the initial rangefeed scan. This was a bug since the timestamp is used to determine which sql instance ID to use when there are two IDs for the same address (i.e., it should use the most recent one). This caused problems if a tenant node was shutdown, then started with the same address. Other layers like DistSQL would try to route requests to an old sql instance, which would actually be the same as the requesting node. No release note since this bug didn't affect anything prior to v22.2. Release justification: high priority bug fix. Release note: None
rafiss
force-pushed
the
fix-multi-tenant-upgrade
branch
from
September 1, 2022 05:09
aebc71d
to
3873bed
Compare
tftr! bors r=ajwerner |
Build succeeded: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fixes #81517
fixes #81506
roachtest: fix ordering of multitenant upgrade test step
The tenant must be initialized by a system tenant using an old binary in
order to be running on an old binary itself.
Also, we no longer finalize the secondary tenant upgrade before finalizing the
system tenant upgrade.
sqlinstance: use the correct timestamp when populating the cache
Previously, the sql instance cache would be populated using the
timestamp of the initial rangefeed scan. This was a bug since the
timestamp is used to determine which sql instance ID to use when there
are two IDs for the same address (i.e., it should use the most recent
one).
This caused problems if a tenant node was shutdown, then started with
the same address. Other layers like DistSQL would try to route requests
to an old sql instance, which would actually be the same as the
requesting node.
Release note: None
Release justification: test only change, and critical bug fix