From f6435cbff1facb875044f8a85d54f03888991ad7 Mon Sep 17 00:00:00 2001 From: MySQL Build Team Date: Tue, 21 Jul 2009 19:59:04 +0200 Subject: [PATCH] Backport into build-200907211706-5.0.82sp1 > ------------------------------------------------------------ > revno: 2772 > revision-id: joro@sun.com-20090615133815-eb007p5793in33p5 > parent: joro@sun.com-20090612140659-4hj1tta9p8wvcw4k > committer: Georgi Kodinov > branch nick: B44810-5.0-bugteam > timestamp: Mon 2009-06-15 16:38:15 +0300 > message: > Bug #44810: index merge and order by with low sort_buffer_size > crashes server! > > The problem affects the scenario when index merge is followed by a filesort > and the sort buffer is not big enough for all the sort keys. > In this case the filesort function will read the data to the end through the > index merge quick access method (and thus closing the cursor etc), > but will leave the pointer to the quick select method in place. > It will then create a temporary file to hold the results of the filesort and > will add it as a sort output file (in sort.io_cache). > Note that filesort will copy the original 'sort' structure in an automatic > variable and restore it after it's done. > As a result at exiting filesort() we have a sort.io_cache filled in and > nothing else (as a result of close of the cursors at end of reading data > through index merge). > Now create_sort_index() will note that there is a select and will clean it up > (as it's been used already by filesort() reading the data in). While doing that > a special case in the index merge destructor will clean up the sort.io_cache, > assuming it's an output of the index merge method and is not needed anymore. > As a result the code that tries to read the data back from the filesort output > will get no data in both memory and disk and will crash. > > Fixed similarly to how filesort() does it : by copying the sort.io_cache structure > to a local variable, removing the pointer to the io_cache (so that it's not freed > by QUICK_INDEX_MERGE_SELECT::~QUICK_INDEX_MERGE_SELECT) and restoring the original > structure (together with the valid pointer) after the cleanup is done. > This is a safe thing to do because all the structures are already cleaned up by > hitting the end of the index merge's read method (QUICK_INDEX_MERGE_SELECT::get_next()) > and the cleanup code being written in a way that tolerates repeating cleanups. --- mysql-test/r/index_merge.result | 24 ++++++++++++++++++++++++ mysql-test/t/index_merge.test | 26 ++++++++++++++++++++++++++ sql/sql_select.cc | 15 +++++++++++++++ 3 files changed, 65 insertions(+) diff --git a/mysql-test/r/index_merge.result b/mysql-test/r/index_merge.result index f3fce29c910..4b3b0fb54fc 100644 --- a/mysql-test/r/index_merge.result +++ b/mysql-test/r/index_merge.result @@ -555,4 +555,28 @@ a 1 2 drop table t0, t1, t2, t3; +# +# BUG#44810: index merge and order by with low sort_buffer_size +# crashes server! +# +CREATE TABLE t1(a VARCHAR(128),b VARCHAR(128),KEY(A),KEY(B)); +INSERT INTO t1 VALUES (REPEAT('a',128),REPEAT('b',128)); +INSERT INTO t1 SELECT * FROM t1; +INSERT INTO t1 SELECT * FROM t1; +INSERT INTO t1 SELECT * FROM t1; +INSERT INTO t1 SELECT * FROM t1; +INSERT INTO t1 SELECT * FROM t1; +INSERT INTO t1 SELECT * FROM t1; +SET SESSION sort_buffer_size=1; +Warnings: +Warning 1292 Truncated incorrect sort_buffer_size value: '1' +EXPLAIN +SELECT * FROM t1 FORCE INDEX(a,b) WHERE a LIKE 'a%' OR b LIKE 'b%' +ORDER BY a,b; +id select_type table type possible_keys key key_len ref rows Extra +1 SIMPLE t1 index_merge a,b a,b 131,131 NULL 64 Using sort_union(a,b); Using where; Using filesort +SELECT * FROM t1 FORCE INDEX(a,b) WHERE a LIKE 'a%' OR b LIKE 'b%' +ORDER BY a,b; +SET SESSION sort_buffer_size=DEFAULT; +DROP TABLE t1; End of 5.0 tests diff --git a/mysql-test/t/index_merge.test b/mysql-test/t/index_merge.test index 7f176a4cd11..ebe0fa42fcd 100644 --- a/mysql-test/t/index_merge.test +++ b/mysql-test/t/index_merge.test @@ -503,4 +503,30 @@ where exists (select 1 from t2, t3 drop table t0, t1, t2, t3; +--echo # +--echo # BUG#44810: index merge and order by with low sort_buffer_size +--echo # crashes server! +--echo # +CREATE TABLE t1(a VARCHAR(128),b VARCHAR(128),KEY(A),KEY(B)); +INSERT INTO t1 VALUES (REPEAT('a',128),REPEAT('b',128)); +INSERT INTO t1 SELECT * FROM t1; +INSERT INTO t1 SELECT * FROM t1; +INSERT INTO t1 SELECT * FROM t1; +INSERT INTO t1 SELECT * FROM t1; +INSERT INTO t1 SELECT * FROM t1; +INSERT INTO t1 SELECT * FROM t1; +SET SESSION sort_buffer_size=1; +EXPLAIN +SELECT * FROM t1 FORCE INDEX(a,b) WHERE a LIKE 'a%' OR b LIKE 'b%' + ORDER BY a,b; +# we don't actually care about the result : we're checking if it crashes +--disable_result_log +SELECT * FROM t1 FORCE INDEX(a,b) WHERE a LIKE 'a%' OR b LIKE 'b%' + ORDER BY a,b; +--enable_result_log + +SET SESSION sort_buffer_size=DEFAULT; +DROP TABLE t1; + + --echo End of 5.0 tests diff --git a/sql/sql_select.cc b/sql/sql_select.cc index 587c0b85ce6..364269e067e 100644 --- a/sql/sql_select.cc +++ b/sql/sql_select.cc @@ -12865,8 +12865,23 @@ create_sort_index(THD *thd, JOIN *join, ORDER *order, tab->records= table->sort.found_records; // For SQL_CALC_ROWS if (select) { + /* + We need to preserve tablesort's output resultset here, because + QUICK_INDEX_MERGE_SELECT::~QUICK_INDEX_MERGE_SELECT (called by + SQL_SELECT::cleanup()) may free it assuming it's the result of the quick + select operation that we no longer need. Note that all the other parts of + this data structure are cleaned up when + QUICK_INDEX_MERGE_SELECT::get_next encounters end of data, so the next + SQL_SELECT::cleanup() call changes sort.io_cache alone. + */ + IO_CACHE *tablesort_result_cache; + + tablesort_result_cache= table->sort.io_cache; + table->sort.io_cache= NULL; + select->cleanup(); // filesort did select tab->select= 0; + table->sort.io_cache= tablesort_result_cache; } tab->select_cond=0; tab->last_inner= 0;