MDEV-32397, MDEV-32403 Crashes during join processing. #3176
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
|
|
DaveGosselin-MariaDB
force-pushed
the
10.5-mdev-32403
branch
2 times, most recently
from
25407d2
to
44fa6db
Compare
spetrunia
requested changes
May 6, 2024
There was a problem hiding this comment.
First comment here:
https://jira.mariadb.org/browse/MDEV-32403?focusedCommentId=284534&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-284534
will follow up in the MDEV.
Queries having the following form may cause a crash SELECT t1.a FROM ( SELECT a AS a1 FROM t1 ) dt JOIN t1 ON a1 LIKE EXISTS ( SELECT a + RAND () FROM t1 UNION SELECT a FROM t1); because the table t1 has some JOIN cleanup operations performed prematurely during the subselect. In this particular case, the presence of RAND() makes the subquery uncacheable, necessitating the need to execute the subquery multiple times during join record evaluation. Each time the subquery runs, it creates its own JOIN structure which has references to the table t1. When the subquery completes, JOIN::cleanup and functions called by it result in ha_end_keyread() being called on table t1. However, we are not done with table t1 because the upper level `select t1.a from...` query requires table t1 to be open. To solve this, we make the executor aware of when we're in subqueries like this and delay JOIN cleanup until the end of the query.
DaveGosselin-MariaDB
force-pushed
the
10.5-mdev-32403
branch
2 times, most recently
from
50c275e
to
6b267ed
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.
Queries having the following form may cause a crash
SELECT t1.a FROM ( SELECT a AS a1 FROM t1 ) dt
JOIN t1 ON a1 LIKE EXISTS ( SELECT a + RAND () FROM t1 UNION SELECT a FROM t1);
because the table t1 has some JOIN cleanup operations performed prematurely during the subselect.
In this particular case, the presence of RAND() makes the subquery uncacheable, necessitating the need to execute the subquery multiple times during join record evaluation. Each time the subquery runs, it creates its own JOIN structure which has references to the table t1. When the subquery completes, JOIN::cleanup and functions called by it result in ha_end_keyread() being called on table t1. However, we are not done with table t1 because the upper level
select t1.a from...query requires table t1 to be open. To solve this, we make the executor aware of when we're in subqueries like this and delay JOIN cleanup until the end of the query.