system-variables: update from generated source#5752
Conversation
|
|
||
| - Scope: GLOBAL | ||
| - Default: `"10m0s"` | ||
| - Default value: 10m0s |
There was a problem hiding this comment.
This value was presented as a "string". If so, I think we can keep the "" quotes. The same for similar cases in this PR.
There was a problem hiding this comment.
If we change this to a string, then the other cases would need to be a string too. It's not that this is incorrect - it's just that it doesn't add any value (all sysvars are actually intepreted as strings). See: https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_flush_method for example on how mysql does it.
eb52e17 to
3e6c4c0
Compare
|
|
||
| - Scope: GLOBAL | ||
| - Default: `"10m0s"` | ||
| - Default value: `10m0s` |
There was a problem hiding this comment.
| - Default value: `10m0s` | |
| - Default value: `10m0s` | |
| - Range: `[10m, 2562047h]` |
5.7.25-TiDB-v5.2.0-alpha-16-gf81ef5579-dirty 127.0.0.1:4000 SQL set global tidb_gc_life_time='10m';
Query OK, 0 rows affected (0.0031 sec)
5.7.25-TiDB-v5.2.0-alpha-16-gf81ef5579-dirty 127.0.0.1:4000 SQL set global tidb_gc_life_time='9m';
ERROR: 1232 (42000): Incorrect argument type to variable 'tidb_gc_life_time'
5.7.25-TiDB-v5.2.0-alpha-16-gf81ef5579-dirty 127.0.0.1:4000 SQL set global tidb_gc_life_time='9m59s';
ERROR: 1232 (42000): Incorrect argument type to variable 'tidb_gc_life_time'
5.7.25-TiDB-v5.2.0-alpha-16-gf81ef5579-dirty 127.0.0.1:4000 SQL set global tidb_gc_life_time='9m60s';
Query OK, 0 rows affected (0.0029 sec)There was a problem hiding this comment.
I'm going to take this up with the team responsible before fixing it. The range here is 292 years, which doesn't really make sense so Golang formats this in minutes with duration.String() method.
I think setting it in code to be a maximum of 1 year is the logical way to handle it.
| - Default value: `OFF` | ||
| - By default, Regions are split for a new table when it is being created in TiDB. After this variable is enabled, the newly split Regions are scattered immediately during the execution of the `CREATE TABLE` statement. This applies to the scenario where data need to be written in batches right after the tables are created in batches, because the newly split Regions can be scattered in TiKV beforehand and do not have to wait to be scheduled by PD. To ensure the continuous stability of writing data in batches, the `CREATE TABLE` statement returns success only after the Regions are successfully scattered. This makes the statement's execution time multiple times longer than that when you disable this variable. | ||
|
|
||
| ### tidb_skip_ascii_check <span class="version-mark">New in v5.0</span> |
There was a problem hiding this comment.
Should we link to the similar setting for UTF-8?
There was a problem hiding this comment.
Thanks! I will do it in a separate PR. For this I'm aiming for parity through an auto-generator.
|
[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. DetailsReviewer can indicate their review by submitting an approval review. |
| - This variable is used to control whether to enable the [baseline capturing](/sql-plan-management.md#baseline-capturing) feature. This feature depends on the statement summary, so you need to enable the statement summary before you use baseline capturing. | ||
| - After this feature is enabled, the historical SQL statements in the statement summary are traversed periodically, and bindings are automatically created for SQL statements that appear at least twice. | ||
|
|
||
| ### tidb_check_mb4_value_in_utf8 |
There was a problem hiding this comment.
Maybe this should link to tidb_skip_utf8_check and/or explain how these are related?
There was a problem hiding this comment.
Thanks! I will do it in a separate PR. For this I'm aiming for parity through an auto-generator.
0d2a1c8 to
58cd968
Compare
|
@TomShawn can we merge this? It will likely start to get merge conflicts. |
|
/merge |
|
This pull request has been accepted and is ready to merge. DetailsCommit hash: 58cd968 |
Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io>
|
In response to a cherrypick label: new pull request created: #5793. |
|
/remove-translation doing |
|
|
||
| - Scope: NONE | ||
| - Default value: 5.7.25-TiDB-(tidb version) | ||
| - Default value: `5.7.25-TiDB-`(tidb version) |
There was a problem hiding this comment.
Follow-up: `5.7.25-TiDB-(tidb version)`
What is changed, added or deleted? (Required)
This updates the system variables, generated against the tidb source code. i.e. this PR is derived from #5720 , but the generator source code will be submitted separately.
This allows this PR to potentially be cherry picked and handled like a regular contribution.
Which TiDB version(s) do your changes apply to? (Required)
What is the related PR or file link(s)?
Do your changes match any of the following descriptions?