1. 06 Jan, 2010 4 commits
  2. 05 Jan, 2010 1 commit
  3. 31 Dec, 2009 2 commits
    • unknown's avatar
      Bug #49137 Replication failure on SBR/MBR + multi-table DROP TEMPORARY TABLE · be397eb4
      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.
      be397eb4
    • unknown's avatar
      Bug #49137 Replication failure on SBR/MBR + multi-table DROP TEMPORARY TABLE · 2b2ce3d6
      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.
      2b2ce3d6
  4. 26 Dec, 2009 2 commits
  5. 24 Dec, 2009 2 commits
  6. 22 Dec, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #49734: Crash on EXPLAIN EXTENDED UNION ... ORDER BY <any non-const-function> · 2d8869d2
      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.
      2d8869d2
  7. 24 Dec, 2009 1 commit
  8. 22 Dec, 2009 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug#49570: Assertion failed: !(order->used & map) · 7344b58c
      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.
      7344b58c
  9. 21 Dec, 2009 1 commit
  10. 18 Dec, 2009 1 commit
  11. 24 Dec, 2009 4 commits
  12. 23 Dec, 2009 3 commits
    • Sergey Glukhov's avatar
      Bug#47649 crash during CALL procedure · 87731177
      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.
      87731177
    • Satya B's avatar
      merge to mysql-5.1-bugteam · 58ccbb7c
      Satya B authored
      58ccbb7c
    • Satya B's avatar
      Applying InnoDB snapshot 5.1-ss6344, Fixes BUG#47814 · 83d5ca95
      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.
      83d5ca95
  13. 22 Dec, 2009 4 commits
    • Satya B's avatar
      merge to mysql-5.1-bugteam · a49b18a7
      Satya B authored
      a49b18a7
    • Satya B's avatar
    • Sergey Glukhov's avatar
      5.0-bugteam->5.1-bugteam merge · c0bd23dd
      Sergey Glukhov authored
      c0bd23dd
    • Sergey Glukhov's avatar
      Bug#47371 reference by same column name · 081bcb3b
      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.
      081bcb3b
  14. 21 Dec, 2009 4 commits
    • Mattias Jonsson's avatar
      merge · df357ed5
      Mattias Jonsson authored
      df357ed5
    • Satya B's avatar
      Applying InnoDB snapshot 5.1-ss6344, part 2. Fixes BUG#41609 but does · 2f04df4a
      Satya B authored
      not address the printouts issue
      
      Detailed revision comments:
      
      r6310 | marko | 2009-12-15 15:23:54 +0200 (Tue, 15 Dec 2009) | 30 lines
      branches/5.1: Merge r4922 from branches/zip.
      
      This the fix for the first part of Bug #41609 from InnoDB Plugin to
      the built-in InnoDB in MySQL 5.1. This allows InnoDB Hot Backup to
      back up a database while the built-in InnoDB in MySQL 5.1 is creating
      temporary tables. (This fix does not address the printouts about
      missing .ibd files for temporary tables at InnoDB startup, which was
      committed to branches/zip in r6252.)
      
      rb://219 approved by Sunny Bains.
      
      branches/zip: Distinguish temporary tables in MLOG_FILE_CREATE.
      This addresses Mantis Issue #23 in InnoDB Hot Backup and some
      of MySQL Bug #41609.
      
      In MLOG_FILE_CREATE, we need to distinguish temporary tables, so that
      InnoDB Hot Backup can work correctly.  It turns out that we can do this
      easily, by using a bit of the previously unused parameter for page number.
      (The page number parameter of MLOG_FILE_CREATE has been written as 0 
      ever since MySQL 4.1, which introduced MLOG_FILE_CREATE.)
      
      MLOG_FILE_FLAG_TEMP: A flag for indicating a temporary table in
      the page number parameter of MLOG_FILE_ operations.
      
      fil_op_write_log(): Add the parameter log_flags.
      
      fil_op_log_parse_or_replay(): Add the parameter log_flags.
      Do not replay MLOG_FILE_CREATE when MLOG_FILE_FLAG_TEMP is set in log_flags.
      This only affects ibbackup --apply-log.  InnoDB itself never replays file
      operations.
      2f04df4a
    • Satya B's avatar
      Applying InnoDB snapshot 5.1-ss6344, part 1. Fixes BUG#49267 · 6559a46a
      Satya B authored
      Detailed revision comments:
      
      r6306 | calvin | 2009-12-14 15:12:46 +0200 (Mon, 14 Dec 2009) | 5 lines
      branches/5.1: fix bug#49267: innodb-autoinc.test fails on windows
      because of different case mode
      
      There is no change to the InnoDB code, only to fix test case by
      changing "T1" to "t1".
      6559a46a
    • He Zhenxing's avatar
      Bug#47638 The rpl_killed_ddl test fails on Windows · 27aba1b5
      He Zhenxing authored
      When the $diff_statement variable for diff_master_slave.inc was
      put in multiple lines, the rear part of the statement would be 
      missing when being executed on Windows systems.
      
      Fixed the problem by always putting the value for $diff_statement
      in one line.
      
      mysql-test/suite/rpl/t/rpl_killed_ddl.test:
        putting the statement for $diff_statement variable in one line.
      27aba1b5
  15. 20 Dec, 2009 1 commit
  16. 18 Dec, 2009 4 commits
    • Davi Arnaut's avatar
      Bug#30331: Table_locks_waited shows inaccurate values · b66b3c16
      Davi Arnaut authored
      Post-merge fix: wait for statement result before disconnecting.
      Otherwise, the statement might affect unrelated tests.
      
      mysql-test/t/lock_multi.test:
        Reap statement status.
      b66b3c16
    • Davi Arnaut's avatar
      Bug#48983: Bad strmake calls (length one too long) · 25be2b28
      Davi Arnaut authored
      MySQL 5.1 specific fixes.
      25be2b28
    • Davi Arnaut's avatar
      Manual merge. · 61ae9288
      Davi Arnaut authored
      61ae9288
    • Magne Mahre's avatar
      Backport to 5.1 branch (next-mr revid: 2921) · f8152464
      Magne Mahre authored
      Bug#35589 SET PASSWORD caused a crash
      Bug#35591 FLUSH PRIVILEGES caused a crash
            
      A race condition on the privilege hash tables (proc_priv_hash
      and func_priv_hash) caused one thread to try to delete elements
      that had already been deleted by another thread.
            
      The bug was caused by reading and saving the pointers to 
      the hash tables outside mutex protection.  This led to an
      inconsistency where a thread copied a pointer to a hash,
      another thread did the same, the first thread then deleted
      the hash, and the second then crashed when it in turn tried to
      delete the deleted hash.
            
      The fix is to ensure that operations on the shared hash structures
      happens under mutex protection (moving the locking up a little)
      f8152464
  17. 17 Dec, 2009 4 commits
    • Jim Winstead's avatar
      Merge approved bug fix · dd1378c8
      Jim Winstead authored
      dd1378c8
    • Jim Winstead's avatar
      Merge with mysql-5.1-bugteam latest changes · a4a064a7
      Jim Winstead authored
      a4a064a7
    • Davi Arnaut's avatar
      Bug#48983: Bad strmake calls (length one too long) · 06a1df91
      Davi Arnaut authored
      The problem is a somewhat common misusage of the strmake function.
      The strmake(dst, src, len) function writes at most /len/ bytes to
      the string pointed to by src, not including the trailing null byte.
      Hence, if /len/ is the exact length of the destination buffer, a
      one byte buffer overflow can occur if the length of the source
      string is equal to or greater than /len/.
      
      client/mysqldump.c:
        Make room for the trailing null byte.
      libmysql/libmysql.c:
        Add comment, there is enough room in the buffer.
        Increase buffer length, two strings are concatenated.
      libmysqld/lib_sql.cc:
        Make room for the trailing null byte.
      mysys/default.c:
        Make room for the trailing null bytes.
      mysys/mf_pack.c:
        Make room for the trailing null byte.
      server-tools/instance-manager/commands.cc:
        Copy only if overflow isn't possible in both cases.
      server-tools/instance-manager/listener.cc:
        Make room for the trailing null byte.
      sql/log.cc:
        Make room for the trailing null byte.
      sql/sp_pcontext.h:
        Cosmetic fix.
      sql/sql_acl.cc:
        MAX_HOSTNAME already specifies space for the trailing null byte.
      sql/sql_parse.cc:
        Make room for the trailing null byte.
      sql/sql_table.cc:
        Make room for the trailing null byte.
      06a1df91
    • Alfranio Correia's avatar
      b1090b13