summaryrefslogtreecommitdiff
path: root/sql/sql_select.cc
diff options
context:
space:
mode:
authorunknown <kaa@kaamos.(none)>2008-03-26 19:37:36 +0300
committerunknown <kaa@kaamos.(none)>2008-03-26 19:37:36 +0300
commitb4b72fb306a1f816c0a39fe4a1eb70fa894ed70b (patch)
treed5a9ce757b38fb53947b1451d1033cca1fdd33a2 /sql/sql_select.cc
parent92a09cf98b8f8abc6c1f1adc987c9826b657f812 (diff)
downloadmariadb-git-b4b72fb306a1f816c0a39fe4a1eb70fa894ed70b.tar.gz
Fix for bug #34928: Confusion by having Primary Key and Index
The bug is a regression introduced in 5.1 by the patch for bug28404. Under some circumstances test_if_skip_sort_order() could leave some data structures in an inconsistent state so that some parts of code could assume the selected execution strategy for GROUP BY/DISTINCT as a loose index scan (e.g. JOIN_TAB::is_using_loose_index_scan()), while the actual strategy chosen was an ordered index scan, which led to wrong data being returned. Fixed test_if_skip_sort_order() so that when changing the type for a join table, select->quick is reset not only for EXPLAIN, but for the actual join execution as well, to not confuse code that depends on its value to determine the chosen GROUP BY/DISTINCT strategy. mysql-test/r/distinct.result: Added a test case for bug #34928. mysql-test/t/distinct.test: Added a test case for bug #34928. sql/sql_select.cc: When changing the table's join type to JT_NEXT in test_if_skip_sort_order(), also reset select->quick because other code may depend on its value to determine the GROUP BY/DISTINCT execution strategy.
Diffstat (limited to 'sql/sql_select.cc')
-rw-r--r--sql/sql_select.cc10
1 files changed, 5 insertions, 5 deletions
diff --git a/sql/sql_select.cc b/sql/sql_select.cc
index 57bcb0b5942..1117df942dd 100644
--- a/sql/sql_select.cc
+++ b/sql/sql_select.cc
@@ -13158,6 +13158,11 @@ test_if_skip_sort_order(JOIN_TAB *tab,ORDER *order,ha_rows select_limit,
tab->read_first_record= best_key_direction > 0 ?
join_read_first:join_read_last;
tab->type=JT_NEXT; // Read with index_first(), index_next()
+ if (select && select->quick)
+ {
+ delete select->quick;
+ select->quick= 0;
+ }
if (table->covering_keys.is_set(best_key))
{
table->key_read=1;
@@ -13168,11 +13173,6 @@ test_if_skip_sort_order(JOIN_TAB *tab,ORDER *order,ha_rows select_limit,
{
tab->ref.key= -1;
tab->ref.key_parts= 0;
- if (select && select->quick)
- {
- delete select->quick;
- select->quick= 0;
- }
if (select_limit < table_records)
tab->limit= select_limit;
}