1. 20 Dec, 2010 3 commits
  2. 17 Dec, 2010 18 commits
  3. 16 Dec, 2010 11 commits
    • Luis Soares's avatar
      empty merge from mysql-5.1-bugteam. · a7087d81
      Luis Soares authored
      a7087d81
    • Luis Soares's avatar
      BUG#46166 · 905e21a0
      Luis Soares authored
      Merging to latest mysql-5.5-bugteam.
      905e21a0
    • Luis Soares's avatar
      BUG#46166 · 60f65006
      Luis Soares authored
      Merging to latest mysql-5.1-bugteam.
      60f65006
    • Alexander Nozdrin's avatar
      Manual merge from mysql-5.5. · a7218610
      Alexander Nozdrin authored
      a7218610
    • Georgi Kodinov's avatar
      merge · 56b06b42
      Georgi Kodinov authored
      56b06b42
    • Georgi Kodinov's avatar
      merge mysql-5.5->mysql-5.5-bugteam · c6b904ab
      Georgi Kodinov authored
      c6b904ab
    • Georgi Kodinov's avatar
      merge · 7bdecb1d
      Georgi Kodinov authored
      7bdecb1d
    • Jorgen Loland's avatar
      BUG#58456 - Assertion 0 in QUICK_INDEX_MERGE_SELECT::need_sorted_output · 664f06de
      Jorgen Loland authored
                  in opt_range.h
      
      In this bug, there are two alternative access plans: 
       * Index merge range access
       * Const ref access
      
      best_access_path() decided that the ref access was preferrable, 
      but make_join_select() still decided to point 
      SQL_SELECT::quick to the index merge because the table had 
      type==JT_CONST which was not handled. 
      
      At the same time the table's ref.key still referred to the 
      index the ref access would use indicating that ref access 
      should be used. In this state, different parts of the 
      optimizer code have different perceptions of which access path
      is in use (ref or range).
      
      test_if_skip_sort_order() was called to check if the ref access
      needed ordering, but test_if_skip_sort_order() got confused and
      requested the index merge to return records in sorted order. 
      Index merge cannot do this, and fired an ASSERT.
      
      The fix is to take join_tab->type==JT_CONST into concideration
      when make_join_select() decides whether or not to use the 
      range access method.
      664f06de
    • Jonathan Perkin's avatar
      Merge from mysql-5.5.8-release · 3d799bdf
      Jonathan Perkin authored
      3d799bdf
    • Jon Olav Hauglid's avatar
      Bug #58730 Assertion failed: table->key_read == 0 in close_thread_table, · 28a5059a
      Jon Olav Hauglid authored
                 temptable views
      
      The TABLE::key_read field indicates if the optimizer has found that row
      retrieval only should access the index tree. The triggered assert
      inside close_thread_table() checks that this field has been reset when
      the table is about to be closed.
      
      During normal execution, these fields are reset right before tables are
      closed at the end of mysql_execute_command(). But in the case of errors,
      tables are closed earlier. The patch for Bug#52044 refactored the open
      tables code so that close_thread_tables() is called immediately if
      opening of tables fails. At this point in the execution, it could
      happend that all TABLE::key_read fields had not been properly reset,
      therefore triggering the assert.
      
      The problematic statement in this case was EXPLAIN where the query
      accessed two derived tables and where the first derived table was
      processed successfully while the second derived table was not.
      Since it was an EXPLAIN, TABLE::key_read fields were not reset after
      successful derived table processing since the state needs to be 
      accessible afterwards. When processing of the second derived table
      failed, it's corresponding SELECT_LEX_UNIT was cleaned, which caused
      it's TABLE::key_read fields to be reset. Since processing failed,
      the error path of open_and_lock_tables() was entered and
      close_thread_tables() was called. The assert was then triggered due
      to the TABLE::key_read fields set during processing of the first
      derived table.
      
      This patch fixes the problem by adding a new derived table processor,
      mysql_derived_cleanup() that is called after mysql_derived_filling().
      It causes cleanup of all SELECT_LEX_UNITs to be called, resetting
      all relevant TABLE::key_read fields.
      
      Test case added to derived.test.
      28a5059a
    • Jonathan Perkin's avatar
      bug#58955: Must -DBUILD_CONFIG=mysql_release require libaio on Linux · caebacaf
      Jonathan Perkin authored
      Allow users to build without aio if they really want to, by passing
      -DIGNORE_AIO_CHECK to cmake.
      caebacaf
  4. 15 Dec, 2010 7 commits
  5. 14 Dec, 2010 1 commit