Fix bug 1619665 (Test innodb.innodb_bug30423 is unstable) #970
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
Backport the 5.6 that masks rows value in EXPLAIN SELECT output for this testcase, as it's not fully deterministic.
|
LGTM |
inikep
pushed a commit
to inikep/percona-server
that referenced
this pull request
Apr 23, 2020
Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook/mysql-5.6@b90e801 Reference Patch: facebook/mysql-5.6@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook/mysql-5.6#970 Reviewed By: lth Differential Revision: D14567846 Pulled By: lth fbshipit-source-id: 826ca05403a
inikep
pushed a commit
to inikep/percona-server
that referenced
this pull request
Feb 24, 2021
Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook/mysql-5.6@b90e801 Reference Patch: facebook/mysql-5.6@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook/mysql-5.6#970 Reviewed By: lth Differential Revision: D14567846 Pulled By: lth fbshipit-source-id: 826ca05403a
inikep
pushed a commit
to inikep/percona-server
that referenced
this pull request
Nov 15, 2021
…percona#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook/mysql-5.6@b90e801 Reference Patch: facebook/mysql-5.6@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook/mysql-5.6#970 Reviewed By: lloyd Differential Revision: D14567846 (facebook/mysql-5.6@7074353) Pulled By: lth fbshipit-source-id: f7a7ed38322
ldonoso
pushed a commit
to ldonoso/percona-server
that referenced
this pull request
Mar 15, 2022
…percona#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook/mysql-5.6@b90e801 Reference Patch: facebook/mysql-5.6@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook/mysql-5.6#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
ldonoso
pushed a commit
to ldonoso/percona-server
that referenced
this pull request
Mar 15, 2022
…percona#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook/mysql-5.6@b90e801 Reference Patch: facebook/mysql-5.6@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook/mysql-5.6#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
ldonoso
pushed a commit
to ldonoso/percona-server
that referenced
this pull request
Mar 18, 2022
…percona#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook/mysql-5.6@b90e801 Reference Patch: facebook/mysql-5.6@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook/mysql-5.6#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
ldonoso
pushed a commit
to ldonoso/percona-server
that referenced
this pull request
Apr 12, 2022
…percona#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook/mysql-5.6@b90e801 Reference Patch: facebook/mysql-5.6@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook/mysql-5.6#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/percona-server
that referenced
this pull request
Apr 17, 2024
…percona#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook/mysql-5.6@b90e801 Reference Patch: facebook/mysql-5.6@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook/mysql-5.6#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
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.
Backport the 5.6 that masks rows value in EXPLAIN SELECT output for
this testcase, as it's not fully deterministic.
http://jenkins.percona.com/job/percona-server-5.5-param/1380/