1. 13 Jan, 2010 3 commits
    • Georgi Kodinov's avatar
      merge 5.1-main to 5.1-bugteam · e8da3df0
      Georgi Kodinov authored
      e8da3df0
    • Sven Sandberg's avatar
      BUG#49222: Mark RAND() as unsafe · 98d04814
      Sven Sandberg authored
      Problem: When RAND() is binlogged in statement mode, the seed is
      binlogged too, so the replication slave generates the same
      sequence of random numbers. This makes replication work in many
      cases, but not in all cases: the order of rows is not guaranteed
      for, e.g., UPDATE or INSERT...SELECT statements, so the row data
      will be different if master and slave retrieve the rows in
      different orders.
      Fix: Mark RAND() as unsafe. It will generate a warning if
      binlog_format=STATEMENT and switch to row-logging if
      binlog_format=ROW.
      
      
      mysql-test/extra/rpl_tests/rpl_row_func003.test:
        updated test case to ignore new warnings
      mysql-test/suite/binlog/r/binlog_unsafe.result:
        updated result file
      mysql-test/suite/binlog/t/binlog_unsafe.test:
        Added test for RAND().
        Also clarified some old comments.
      mysql-test/suite/rpl/r/rpl_misc_functions.result:
        updated result file
      mysql-test/suite/rpl/r/rpl_nondeterministic_functions.result:
        updated test case to ignore new warnings
      mysql-test/suite/rpl/r/rpl_optimize.result:
        updated result file
      mysql-test/suite/rpl/r/rpl_row_func003.result:
        updated result file
      mysql-test/suite/rpl/t/rpl_misc_functions.test:
        updated test case to ignore new warnings
      mysql-test/suite/rpl/t/rpl_nondeterministic_functions.test:
        updated test case to ignore new warnings
      mysql-test/suite/rpl/t/rpl_optimize.test:
        updated test case to ignore new warnings
      mysql-test/suite/rpl/t/rpl_trigger.test:
        updated test case to ignore new warnings
      mysql-test/suite/rpl_ndb/r/rpl_ndb_func003.result:
        updated result file
      sql/item_create.cc:
        Mark RAND() unsafe.
      98d04814
    • Gleb Shchepa's avatar
      Bug #50096: CONCAT_WS inside procedure returning wrong data · 16722458
      Gleb Shchepa authored
      Selecting of the CONCAT_WS(...<PS parameter>...) result into
      a user variable may return wrong data.
      
      Item_func_concat_ws::val_str contains a number of memory
      allocation-saving optimization tricks. After the fix
      for bug 46815 the control flow has been changed to a
      branch that is commented as "This is quite uncommon!":
      one of places where we are trying to concatenate
      strings inplace. However, that "uncommon" place
      didn't care about PS parameters, that have another
      trick in Item_sp_variable::val_str(): they use the
      intermediate Item_sp_variable::str_value field,
      where they may store a reference to an external
      argument's buffer.
      
      The Item_func_concat_ws::val_str function has been
      modified to take into account val_str functions
      (such as Item_sp_variable::val_str) that return a
      pointer to an internal Item member variable that
      may reference to a buffer provided.
      
      
      mysql-test/r/func_concat.result:
        Added test case for bug #50096.
      mysql-test/t/func_concat.test:
        Added test case for bug #50096.
      sql/item_strfunc.cc:
        Bug #50096: CONCAT_WS inside procedure returning wrong data
        
        The Item_func_concat_ws::val_str function has been
        modified to take into account val_str functions
        (such as Item_sp_variable::val_str) that return a
        pointer to an internal Item member variable that
        may reference to a buffer provided.
      16722458
  2. 11 Jan, 2010 3 commits
    • Joerg Bruehe's avatar
      Implement the change of RPM versioning and file naming: · 4534b49c
      Joerg Bruehe authored
      - "release" starts from 1
      - "level" ("m2", "rc", ...) is included in the RPM version.
      4534b49c
    • Gleb Shchepa's avatar
      9e9cccaa
    • Gleb Shchepa's avatar
      Bug #49955: ld error message: undefined reference to `strmov_overlapp' · 2976c8fc
      Gleb Shchepa authored
      32bit builds with the --enable-assembler flag (enabled by default)
      fail with an error message: undefined reference to `strmov_overlapp'.
      
      Since the fix for bug 48866 we use a home-grown strmov function
      instead of the ctpcpy function, but the source file for this
      function was missed in the Makefile.am.
      
      The strings/Makefile.am file has been modified to include strmov.c
      file into ASSEMBLER_x86 and ASSEMBLER_sparc32 sections.
      
      
      strings/Makefile.am:
        Bug #49955: ld error message: undefined reference to `strmov_overlapp'
        
        The strings/Makefile.am file has been modified to include
        strmov.c file into ASSEMBLER_x86 and ASSEMBLER_sparc32 sections.
      2976c8fc
  3. 08 Jan, 2010 2 commits
    • unknown's avatar
      Postfix · 054ca1b5
      unknown authored
      Recover the right contents of the index file at the end of the test case.
      054ca1b5
    • unknown's avatar
      BUG #28421 Infinite loop on slave relay logs · bc4b0557
      unknown authored
      Manually deleteing one or more entries from 'master-bin.index', will
      cause master infinitely loop to send one binlog file. 
      
      When starting a dump session, master opens index file and search the binlog file
      which is being requested by the slave. The position of the binlog file in the
      index file is recorded. it will be used to find the next binlog file when current
      binlog file has dumped completely. As only the position is used, it may
      not get the correct file if some entries has been removed manually from the index file.
      the master will reopen the current binlog file which has been dump completely
      and redump it if it can not get the next binlog file's name from index file.
      It obviously is a logical error.
      
      
      Even though it is allowed to manually change index file,
      but it is not recommended. so after this patch, master
      sends a fatal error to slave and close the dump session if a new binlog file
      has been generated and master can not get it from the index file.
      bc4b0557
  4. 07 Jan, 2010 1 commit
  5. 06 Jan, 2010 5 commits
  6. 05 Jan, 2010 1 commit
  7. 31 Dec, 2009 2 commits
    • unknown's avatar
      Bug #49137 Replication failure on SBR/MBR + multi-table DROP TEMPORARY TABLE · 6227bfe0
      unknown authored
            
      In statement-based or mixed-mode replication, use DROP TEMPORARY TABLE
      to drop multiple tables causes different errors on master and slave, 
      when one or more of these tables do not exist. Because when executed
      on slave, it would automatically add IF EXISTS to the query to ignore
      all ER_BAD_TABLE_ERROR errors.
      
      To fix the problem, do not add IF EXISTS when executing DROP TEMPORARY
      TABLE on the slave, and clear the ER_BAD_TABLE_ERROR error after
      execution if the query does not expect any errors.
      
      mysql-test/suite/rpl/r/rpl_drop_temp.result:
        Updated for the patch of bug#49137.
      mysql-test/suite/rpl/t/rpl_drop_temp.test:
        Added the test file to verify if DROP MULTI TEMPORARY TABLE
        will cause different errors on master and slave, when one or
        more of these tables do not exist.
      sql/log_event.cc:
        Added code to handle above cases which are 
        removed from sql_parse.cc
      sql/sql_parse.cc:
        Remove the code to issue the 'Unknown table' error, 
        if the temporary table does not exist when dropping 
        it on slave. The above cases decribed in comments
        will be handled later in log_event.cc.
      6227bfe0
    • unknown's avatar
      Bug #49137 Replication failure on SBR/MBR + multi-table DROP TEMPORARY TABLE · 28baa532
      unknown authored
            
      In statement-based or mixed-mode replication, use DROP TEMPORARY TABLE
      to drop multiple tables causes different errors on master and slave, 
      when one or more of these tables do not exist. Because when executed
      on slave, it would automatically add IF EXISTS to the query to ignore
      all ER_BAD_TABLE_ERROR errors.
      
      To fix the problem, do not add IF EXISTS when executing DROP TEMPORARY
      TABLE on the slave, and clear the ER_BAD_TABLE_ERROR error after
      execution if the query does not expect any errors.
      
      
      mysql-test/r/rpl_drop_temp.result:
        Updated for the patch of bug#49137.
      mysql-test/t/rpl_drop_temp.test:
        Added the test file to verify if DROP MULTI TEMPORARY TABLE
        will cause different errors on master and slave, when one or
        more of these tables do not exist.
      sql/log_event.cc:
        Added code to handle above cases which are
        removed from sql_parse.cc
      sql/sql_parse.cc:
        Remove the code to issue the 'Unknown table' error,
        if the temporary table does not exist when dropping
        it on slave. The above cases decribed in comments
        will be handled later in log_event.cc.
      28baa532
  8. 30 Dec, 2009 2 commits
  9. 26 Dec, 2009 2 commits
  10. 24 Dec, 2009 2 commits
  11. 22 Dec, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #49734: Crash on EXPLAIN EXTENDED UNION ... ORDER BY <any non-const-function> · 83437f46
      Georgi Kodinov authored
      Several problems fixed : 
      1. Non constant expressions in UNION ... ORDER BY were not correctly cleaned up
      in st_select_lex_unit::cleanup() causing crashes in EXPLAIN EXTENDED because of
      fields quoted by these expressions pointing to the already freed temporary table
      used to calculate the UNION.
      Fixed by correctly cleaning up expressions of any depth.
      
      2. Subqueries in the order by part of UNION ... ORDER BY ... caused a crash in 
      EXPLAIN EXTENDED because of a transformation attempt made during EXPLAIN EXTENDED
      execution. Fixed by not doing the transformation when in EXPLAIN.
      
      3. Fulltext functions caused crash when in the ORDER BY part of an un-parenthesized
      UNION that gets "promoted" to be valid for the whole union, e.g. 
      SELECT * FROM t1 UNION SELECT * FROM t2 ORDER BY MATCHES (a) AGAINST ('abc' IN BOOLEAN MODE).
      This is a case that demonstrates a more general problem of parts of the query being
      moved to another level. When doing such transformation late in the optimization run
      when most of the flags about the contents of the query are already aggregated it's possible 
      to "split" the flags so that they correctly reflect the new queries after the transformation.
      In specific the ST_SELECT_LEX::ftfunc_list is holding all the free text function for all the 
      parts of the second SELECT in the UNION and we don't know what part of that is in the ORDER BY
      that we're to move to the UNION level and what part is about the other parts of the second SELECT.
      Fixed by throwing and error when such statements are about to be processed by adding a check 
      for the presence of MATCH() inside the ORDER BY clause that's going to get promoted to UNION.
      To workaround this new limitation one must parenthesize the UNION SELECTs and provide a real 
      global ORDER BY for the UNION outside of the parenthesis.
      83437f46
  12. 24 Dec, 2009 1 commit
  13. 22 Dec, 2009 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug#49570: Assertion failed: !(order->used & map) · 6bc9c950
      Ramil Kalimullin authored
      on re-execution of prepared statement
      
      Problem: some (see eq_ref_table()) ORDER BY/GROUP BY optimization
      is called before each PS execution. However, we don't properly 
      initialize its stucture every time before the call.
      
      Fix: properly initialize the sturture used.
      
      
      
      mysql-test/r/ps.result:
        Fix for bug#49570: Assertion failed: !(order->used & map) 
        on re-execution of prepared statement
          - test result.
      mysql-test/t/ps.test:
        Fix for bug#49570: Assertion failed: !(order->used & map) 
        on re-execution of prepared statement
          - test case.
      sql/sql_select.cc:
        Fix for bug#49570: Assertion failed: !(order->used & map) 
        on re-execution of prepared statement
          - set order->used to 0 before each eq_ref_table() call,
        as the function relies on that.
      6bc9c950
  14. 21 Dec, 2009 1 commit
  15. 18 Dec, 2009 1 commit
  16. 24 Dec, 2009 4 commits
  17. 23 Dec, 2009 3 commits
    • Sergey Glukhov's avatar
      Bug#47649 crash during CALL procedure · 02012436
      Sergey Glukhov authored
      If first call of the procedure is failed on
      the open_table stage stmt_arena->state is set to
      EXECUTED state. On second call(if no errors on
      open_table stage) it leads to use of worng memory arena
      in find_field_in_view() function as
      thd->stmt_arena->is_stmt_prepare_or_first_sp_execute()
      returns FALSE for EXECUTED state. The item is created 
      not in its own arena and it leads to crash on further
      calls of the procedure.
      The fix: 
      change state of arena only if
      no errors on open_table stage happens.
      
      
      mysql-test/r/sp.result:
        test result
      mysql-test/t/sp.test:
        test case
      sql/sp_head.cc:
        If first call of the procedure is failed on
        the open_table stage stmt_arena->state is set to
        EXECUTED state. On second call(if no errors on
        open_table stage) it leads to use of worng memory arena
        in find_field_in_view() function as
        thd->stmt_arena->is_stmt_prepare_or_first_sp_execute()
        returns FALSE for EXECUTED state. The item is created 
        not in its own arena and it leads to crash on further
        calls of the procedure.
        The fix: 
        change state of arena only if
        no errors on open_table stage happens.
      02012436
    • Satya B's avatar
      merge to mysql-5.1-bugteam · dafd6c8a
      Satya B authored
      dafd6c8a
    • Satya B's avatar
      Applying InnoDB snapshot 5.1-ss6344, Fixes BUG#47814 · 382e6f41
      Satya B authored
      and also applying 5.1-ss6355
      
      Detailed revision comments:
      
      r6324 | jyang | 2009-12-17 06:54:24 +0200 (Thu, 17 Dec 2009) | 8 lines
      branches/5.1: Fix bug #47814 - Diagnostics are frequently not
      printed after a long lock wait in InnoDB. Separate out the 
      lock wait timeout check thread from monitor information
      printing thread.
      
      rb://200 Approved by Marko.
      
      r6349 | marko | 2009-12-22 11:09:54 +0200 (Tue, 22 Dec 2009) | 3 lines
      branches/5.1: lock_print_info_summary(): Remove a reference to
      innobase_mysql_end_print_arbitrary_thd() that should have been
      removed in r6347 when removing the function.
      
      r6350 | marko | 2009-12-22 11:11:09 +0200 (Tue, 22 Dec 2009) | 1 line
      branches/5.1: Remove an obsolete declaration of LOCK_thread_count.
      382e6f41
  18. 22 Dec, 2009 4 commits
    • Satya B's avatar
      merge to mysql-5.1-bugteam · db11595c
      Satya B authored
      db11595c
    • Satya B's avatar
    • Sergey Glukhov's avatar
      5.0-bugteam->5.1-bugteam merge · 0a84c51f
      Sergey Glukhov authored
      0a84c51f
    • Sergey Glukhov's avatar
      Bug#47371 reference by same column name · 1cffb859
      Sergey Glukhov authored
      At the end of execution top level join execution
      we cleanup this join with true argument.
      It leads to underlying join cleanup(subquery) with true argument too
      and to tmp_table_param->field array cleanup which is required later.
      The problem is that Item_func_set_user_var does not set
      result_filed which leads to unnecessary repeated excution of subquery
      on final stage.
      The fix is to set result_field for Item_func_set_user_var.
      
      
      mysql-test/r/count_distinct.result:
        test result
      mysql-test/r/user_var.result:
        test result
      mysql-test/t/count_distinct.test:
        test case
      mysql-test/t/user_var.test:
        test case
      sql/item_func.cc:
        At the end of execution top level join execution
        we cleanup this join with true argument.
        It leads to underlying join cleanup(subquery) with true argument too
        and to tmp_table_param->field array cleanup which is required later.
        The problem is that Item_func_set_user_var does not set
        result_filed which leads to unnecessary repeated excution of subquery
        on final stage.
        The fix is to set result_field for Item_func_set_user_var.
      1cffb859
  19. 21 Dec, 2009 1 commit