-
Notifications
You must be signed in to change notification settings - Fork 5.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
*: better handle sysvar upgrades from older versions #31583
Conversation
[REVIEW NOTIFICATION] This pull request has been approved by:
To complete the pull request process, please ask the reviewers in the list to review by filling The full list of commands accepted by this bot can be found here. Reviewer can indicate their review by submitting an approval review. |
/run-unit-test |
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.
I thought about this, but it does change the value of old settings. Maybe warnings are needed.
The behavior itself also deserve a release note and possibly documentation changes.
/cc @bb7133 |
The old settings are considered invalid, and the validation function does not know how to make them valid. In theory we could ask the caller to handle the error (current behavior), but the problem is even though it has context it probably won't do a better job. Edit: Ideally as we retire invalid settings, we should create bootstrap tasks to covert the old values. This will handle the cases in a "contextually aware" way. But this serves as a fallback when there is no bootstrap task. |
Yes, it's 100% possible to script and automate by iterating through git tags and exporting the values. We can then validate the values against master's validation function. @easonn7 can you confirm what the spread of supported upgrades is? |
Code Coverage Details: https://codecov.io/github/pingcap/tidb/commit/af3a5472f2b1930e736811a5da290d4b3524eaa6 |
require.Error(t, err) | ||
require.Error(t, err, variable.ErrWrongTypeForVar.GenWithStackByArgs("max_user_connections").Error()) |
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.
So it's still a compatibility breaker? I'll add a label.
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.
Sure. We can add the label, but it is not very likely since this was only introduced in #31566 (5.4) - This PR reverts the previous PR with one that handles noops and other sysvars.
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
/merge |
This pull request has been accepted and is ready to merge. Commit hash: bcc5383
|
Signed-off-by: ti-srebot <[email protected]>
cherry pick to release-5.4 in PR #32997 |
What problem does this PR solve?
Issue Number: close #31538
Problem Summary:
In v5.4 the
GetGlobalSysVar()
function returns an error if loading the value of a sysvar fails validation (in prior versions; no validation was performed at all, so this can be seen as a regression of #30293 ).While this could be fixed by adjusting
SHOW VARIABLES
to handle these errors, it seems easier if we consistently handle upgrade issues in theGetGlobalSysVar()
function in a determinstic way: replacing the default value if validation fails.This also adds tests around system variable upgrades, which unfortunately were lacking previously.
This effectively reverts #31566 because it handles the issue in a different part of the code.
What is changed and how it works?
Check List
Tests
Side effects
Minor incompatibility: In 5.4 (and only 5.4) it was possible that some noop sysvars permitted incorrect values to be set. These now return an error again as in 5.3 and below.
Documentation
Release note