1. 20 Dec, 2010 1 commit
  2. 17 Dec, 2010 18 commits
  3. 16 Dec, 2010 11 commits
    • Luis Soares's avatar
      empty merge from mysql-5.1-bugteam. · b4fe0e0c
      Luis Soares authored
      b4fe0e0c
    • Luis Soares's avatar
      BUG#46166 · b0e77d62
      Luis Soares authored
      Merging to latest mysql-5.5-bugteam.
      b0e77d62
    • Luis Soares's avatar
      BUG#46166 · 2d9080ff
      Luis Soares authored
      Merging to latest mysql-5.1-bugteam.
      2d9080ff
    • Alexander Nozdrin's avatar
      Manual merge from mysql-5.5. · 3237e490
      Alexander Nozdrin authored
      3237e490
    • Georgi Kodinov's avatar
      merge · 3a1eb900
      Georgi Kodinov authored
      3a1eb900
    • Georgi Kodinov's avatar
      merge mysql-5.5->mysql-5.5-bugteam · 74e2520c
      Georgi Kodinov authored
      74e2520c
    • Georgi Kodinov's avatar
      merge · b908a74b
      Georgi Kodinov authored
      b908a74b
    • Jorgen Loland's avatar
      BUG#58456 - Assertion 0 in QUICK_INDEX_MERGE_SELECT::need_sorted_output · 47b774b2
      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.
      
      mysql-test/r/join_outer_innodb.result:
        Add test for BUG#58456
      mysql-test/t/join_outer_innodb.test:
        Add test for BUG#58456
      47b774b2
    • Jonathan Perkin's avatar
      Merge from mysql-5.5.8-release · 33827e7d
      Jonathan Perkin authored
      33827e7d
    • Jon Olav Hauglid's avatar
      Bug #58730 Assertion failed: table->key_read == 0 in close_thread_table, · 8b1571d8
      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.
      8b1571d8
    • Jonathan Perkin's avatar
      bug#58955: Must -DBUILD_CONFIG=mysql_release require libaio on Linux · 5752c16c
      Jonathan Perkin authored
      Allow users to build without aio if they really want to, by passing
      -DIGNORE_AIO_CHECK to cmake.
      5752c16c
  4. 15 Dec, 2010 7 commits
    • Davi Arnaut's avatar
      Bug#58136: Crash in vio_close at concurrent disconnect and KILL · 4e2cf441
      Davi Arnaut authored
      The problem is a race between a session closing its vio
      (i.e. after a COM_QUIT) at the same time it is being killed by
      another thread. This could trigger a assertion in vio_close()
      as the two threads could end up closing the same vio, at the
      same time. This could happen due to the implementation of
      SIGNAL_WITH_VIO_CLOSE, which closes the vio of the thread
      being killed.
      
      The solution is to serialize the close of the Vio under
      LOCK_thd_data, which protects THD data.
      
      No regression test is added as this is essentially a debug
      issue and the test case would be quite convoluted as we would
      need to synchronize a session that is being killed -- which
      is a bit difficult since debug sync points code does not
      synchronize killed sessions.
      
      sql/mysqld.cc:
        Drop lock parameter from close_connection, its not necessary
        any more. The newly introduced THD::disconnect method will take
        care of locking.
      sql/mysqld.h:
        Change prototype, add a default parameter for the error code.
      sql/sql_class.cc:
        In case SIGNAL_WITH_VIO_CLOSE is defined, the active vio is
        closed and cleared. Subsequent calls will only close the vio
        owned by the session.
      4e2cf441
    • Davi Arnaut's avatar
      Bug#58953: 5.5 does not build with -DWITHOUT_PERFSCHEMA_STORAGE_ENGINE=1 · 4ccb32c0
      Davi Arnaut authored
      The MYSQL_LOG::open member function does not take a PSI
      key file argument when the PSI interface is not present.
      4ccb32c0
    • Davi Arnaut's avatar
      Add VERSION.dep to the bzr ignore list. The file is generated · 5eab43b4
      Davi Arnaut authored
      automatically to place a dependency on the VERSION file.
      5eab43b4
    • Davi Arnaut's avatar
      Bug#58871: Reorganize maintainer mode compiler flags to allow · 650d9cc5
      Davi Arnaut authored
                 option for specific compilers
      
      Reorganize the maintainer mode cmake code to allow options
      for specific compilers. For now, enable -Wcheck for ICC,
      but do not turn warnings into errors.
      
      CMakeLists.txt:
        Move the code that sets options to cmake/maintainer.cmake
      cmake/maintainer.cmake:
        Add macros for each specific compiler.
      650d9cc5
    • Davi Arnaut's avatar
      Cleanup my_win_init by moving time and registry related · 7941c7ea
      Davi Arnaut authored
      initialization to specific functions. Also, remove a large
      block of white space. There shouldn't be any functional
      change.
      7941c7ea
    • Alexander Barkov's avatar
      Bug#58321 No warning when characters outside BMP0 is converted to UCS2 · ac665ecf
      Alexander Barkov authored
      Problem: when inserting supplementary characters to an UCS2 column,
      character was silently shrinked to 16-bit value.
      
      Fix: produce a warning on attempt to insert a supplementary character,
      and convert to question mark.
      
        @ mysql-test/r/ctype_many.result
        @ mysql-test/t/ctype_many.test
        Adding tests
      
        @ strings/ctype-ucs2.c
        Check if wc is greater than the highest value supported (0xFFFF),
        return MY_CS_ILUNI if true.
      ac665ecf
    • Sunanda Menon's avatar
      Merge from mysql-5.1.54-release · f1431e15
      Sunanda Menon authored
      f1431e15
  5. 14 Dec, 2010 3 commits
    • Gleb Shchepa's avatar
      automerge 5.1-bugteam --> 5.5-bugteam · 935ca4b3
      Gleb Shchepa authored
      935ca4b3
    • Gleb Shchepa's avatar
    • Gleb Shchepa's avatar
      backport of bug #54476 fix from 5.1-bugteam to 5.0-bugteam. · 086130e3
      Gleb Shchepa authored
      Original revid: alexey.kopytov@sun.com-20100723115254-jjwmhq97b9wl932l
      
       > Bug #54476: crash when group_concat and 'with rollup' in
       >                      prepared statements
       >
       > Using GROUP_CONCAT() together with the WITH ROLLUP modifier
       > could crash the server.
       >
       > The reason was a combination of several facts:
       >
       > 1. The Item_func_group_concat class stores pointers to ORDER
       > objects representing the columns in the ORDER BY clause of
       > GROUP_CONCAT().
       >
       > 2. find_order_in_list() called from
       > Item_func_group_concat::setup() modifies the ORDER objects so
       > that their 'item' member points to the arguments list
       > allocated in the Item_func_group_concat constructor.
       >
       > 3. In some cases (e.g. in JOIN::rollup_make_fields) a copy of
       > the original Item_func_group_concat object could be created by
       > using the Item_func_group_concat::Item_func_group_concat(THD
       > *thd, Item_func_group_concat *item) copy constructor. The
       > latter essentially creates a shallow copy of the source
       > object. Memory for the arguments array is allocated on
       > thd->mem_root, but the pointers for arguments and ORDER are
       > copied verbatim.
       >
       > What happens in the test case is that when executing the query
       > for the first time, after a copy of the original
       > Item_func_group_concat object has been created by
       > JOIN::rollup_make_fields(), find_order_in_list() is called for
       > this new object. It then resolves ORDER BY by modifying the
       > ORDER objects so that they point to elements of the arguments
       > array which is local to the cloned object. When thd->mem_root
       > is freed upon completing the execution, pointers in the ORDER
       > objects become invalid. Those ORDER objects, however, are also
       > shared with the original Item_func_group_concat object which is
       > preserved between executions of a prepared statement. So the
       > first call to find_order_in_list() for the original object on
       > the second execution tries to dereference an invalid pointer.
       >
       > The solution is to create copies of the ORDER objects when
       > copying Item_func_group_concat to not leave any stale pointers
       > in other instances with different lifecycles.
      
      
      mysql-test/r/func_gconcat.result:
        Test case for bug #54476.
      mysql-test/t/func_gconcat.test:
        Test case for bug #54476.
      sql/item_sum.cc:
        Copy the ORDER objects pointed to by the elements of the
        'order' array in the copy constructor of
        Item_func_group_concat.
      sql/table.h:
        Removed the unused 'item_copy' member of the ORDER class.
      086130e3