MDEV-38099: Assertion failed in st_select_lex::optimize_unflattened_s… #4538
Conversation
This file contains hidden or 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
…ubqueries When optimizing unflattened subqueries we assert that, if any SELECT in a unit sets the uncacheable flag with UNCACHEABLE_RAND, then the unit's uncacheable flag itself should be set likewise. Put another way, any SELECT in the unit that is UNCACHEABLE_RAND causes the entire unit to be so marked. However, this marking was not preserved by SELECT_LEX::register_unit when registering a new unit. During that method, the SELECT_LEX's uncacheable value is updated with the registered unit's uncacheable value but, if the UNCACHEABLE_RAND marking is present, it is not propagated to the uncacheable flag of the enclosing unit. If the incoming unit's uncacheable flag has the UNCACHEABLE_RAND bit set and if the master unit exists, then set the UNCACHEABLE_RAND flag on the master unit.
DaveGosselin-MariaDB
force-pushed
the
12.2-MDEV-38099-assertion-fail
branch
from
a5504f0 to
2e253ef
Compare
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.
…ubqueries
When optimizing unflattened subqueries we assert that, if any SELECT in a unit sets the uncacheable flag with UNCACHEABLE_RAND, then the unit's uncacheable flag itself should be set likewise. Put another way, any SELECT in the unit that is UNCACHEABLE_RAND causes the entire unit to be so marked.
However, this marking was not preserved by SELECT_LEX::register_unit when registering a new unit. During that method, the SELECT_LEX's uncacheable value is updated with the registered unit's uncacheable value but, if the UNCACHEABLE_RAND marking is present, it is not propagated to the uncacheable flag of the enclosing unit.
If the incoming unit's uncacheable flag has the UNCACHEABLE_RAND bit set and if the master unit exists, then set the UNCACHEABLE_RAND flag on the master unit.