1. 05 Jan, 2010 1 commit
  2. 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
  3. 26 Dec, 2009 2 commits
  4. 24 Dec, 2009 2 commits
  5. 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
  6. 24 Dec, 2009 1 commit
  7. 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
  8. 21 Dec, 2009 1 commit
  9. 18 Dec, 2009 1 commit
  10. 24 Dec, 2009 4 commits
  11. 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
  12. 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
  13. 21 Dec, 2009 4 commits
    • Mattias Jonsson's avatar
      merge · 9d9a237d
      Mattias Jonsson authored
      9d9a237d
    • Satya B's avatar
      Applying InnoDB snapshot 5.1-ss6344, part 2. Fixes BUG#41609 but does · 50badcaa
      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.
      50badcaa
    • Satya B's avatar
      Applying InnoDB snapshot 5.1-ss6344, part 1. Fixes BUG#49267 · 88697da6
      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".
      88697da6
    • He Zhenxing's avatar
      Bug#47638 The rpl_killed_ddl test fails on Windows · 652bced5
      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.
      652bced5
  14. 20 Dec, 2009 1 commit
  15. 18 Dec, 2009 4 commits
    • Davi Arnaut's avatar
      Bug#30331: Table_locks_waited shows inaccurate values · fa7ae6f8
      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.
      fa7ae6f8
    • Davi Arnaut's avatar
      Bug#48983: Bad strmake calls (length one too long) · 8b79b8fd
      Davi Arnaut authored
      MySQL 5.1 specific fixes.
      8b79b8fd
    • Davi Arnaut's avatar
      Manual merge. · 95e34182
      Davi Arnaut authored
      95e34182
    • Magne Mahre's avatar
      Backport to 5.1 branch (next-mr revid: 2921) · fa438192
      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)
      fa438192
  16. 17 Dec, 2009 8 commits
    • Jim Winstead's avatar
      Merge approved bug fix · e282e07c
      Jim Winstead authored
      e282e07c
    • Jim Winstead's avatar
      Merge with mysql-5.1-bugteam latest changes · 62ad664a
      Jim Winstead authored
      62ad664a
    • Davi Arnaut's avatar
      Bug#48983: Bad strmake calls (length one too long) · c2fb2a9a
      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.
      c2fb2a9a
    • Alfranio Correia's avatar
      730f52c6
    • Andrei Elkin's avatar
      merge from 5.0 with bug@49740 fixes · f0b07e7b
      Andrei Elkin authored
      f0b07e7b
    • Andrei Elkin's avatar
      Bug #49740 rpl.rpl_temporary fails in PB2 in mysql-trunk-merge · 119349c1
      Andrei Elkin authored
      The test allowed random coincidence of connection ids for two concurrent
      sessions performing CREATE/DROP temp tables.
      
      Fixed with correcting the test. The sessions connection ids are not changed
      from their defaults anymore.
      119349c1
    • Satya B's avatar
      merge to mysql-5.1-bugteam · f757b63e
      Satya B authored
      f757b63e
    • Satya B's avatar
      merge mysql-5.0-bugteam to mysql-5.1-bugteam · 4fa9b44c
      Satya B authored
      4fa9b44c