diff options
| author | Sergei Petrunia <psergey@askmonty.org> | 2021-04-29 19:30:07 +0300 |
|---|---|---|
| committer | Sergei Petrunia <psergey@askmonty.org> | 2021-04-30 21:42:14 +0300 |
| commit | 2820f30dde3148df71e1d748ac705d98d60e0787 (patch) | |
| tree | 39bbab92fd829ca8fcbe568056edf99b19ceaec0 /sql/sql_select.cc | |
| parent | 8f9a72a1504c73a2d432cb5a521b9ca631d1e455 (diff) | |
| download | mariadb-git-bb-10.3-mdev23723.tar.gz | |
MDEV-23723: Crash when test_if_skip_sort_order() is checked for derived ...bb-10.3-mdev23723
The problem was caused by the following scenario:
Subquery's table has two indexes, KEY a(a), KEY a_b(a,b)
- LATERAL DERIVED optimization decides to use index a.
= The subquery uses ref access over key a.
- test_if_skip_sort_order() sees that KEY a_b satisfies the
subquery's GROUP BY clause, and attempts to switch to it.
= It fails to do so, because KEYUSE objects for index a_b
are switched off.
Fixed by disallowing to change the ref access key if it uses KEYUSE
objects injected by LATERAL DERIVED optimization.
Diffstat (limited to 'sql/sql_select.cc')
| -rw-r--r-- | sql/sql_select.cc | 5 |
1 files changed, 4 insertions, 1 deletions
diff --git a/sql/sql_select.cc b/sql/sql_select.cc index 2526866e534..6c090ea5352 100644 --- a/sql/sql_select.cc +++ b/sql/sql_select.cc @@ -10102,6 +10102,7 @@ static bool create_ref_for_key(JOIN *join, JOIN_TAB *j, j->ref.disable_cache= FALSE; j->ref.null_ref_part= NO_REF_PART; j->ref.const_ref_part_map= 0; + j->ref.uses_splitting= FALSE; keyuse=org_keyuse; store_key **ref_key= j->ref.key_copy; @@ -10150,6 +10151,7 @@ static bool create_ref_for_key(JOIN *join, JOIN_TAB *j, j->ref.null_rejecting|= (key_part_map)1 << i; keyuse_uses_no_tables= keyuse_uses_no_tables && !keyuse->used_tables; + j->ref.uses_splitting |= (keyuse->validity_ref != NULL); /* We don't want to compute heavy expressions in EXPLAIN, an example would select * from t1 where t1.key=(select thats very heavy); @@ -22536,7 +22538,8 @@ test_if_skip_sort_order(JOIN_TAB *tab,ORDER *order,ha_rows select_limit, todo: why does JT_REF_OR_NULL mean filesort? We could find another index that satisfies the ordering. I would just set ref_key=MAX_KEY here... */ - if (tab->type == JT_REF_OR_NULL || tab->type == JT_FT) + if (tab->type == JT_REF_OR_NULL || tab->type == JT_FT || + tab->ref.uses_splitting) goto use_filesort; } else if (select && select->quick) // Range found by opt_range |