1. 11 Jan, 2010 3 commits
    • Joerg Bruehe's avatar
      Implement the change of RPM versioning and file naming: · 3c9322e7
      Joerg Bruehe authored
      - "release" starts from 1
      - "level" ("m2", "rc", ...) is included in the RPM version.
      3c9322e7
    • Gleb Shchepa's avatar
      a852f464
    • Gleb Shchepa's avatar
      Bug #49955: ld error message: undefined reference to `strmov_overlapp' · 107f34ed
      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.
      107f34ed
  2. 08 Jan, 2010 2 commits
    • unknown's avatar
      Postfix · 4ae5679f
      unknown authored
      Recover the right contents of the index file at the end of the test case.
      4ae5679f
    • unknown's avatar
      BUG #28421 Infinite loop on slave relay logs · c1043021
      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.
      c1043021
  3. 07 Jan, 2010 1 commit
  4. 06 Jan, 2010 5 commits
  5. 05 Jan, 2010 1 commit
  6. 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
  7. 26 Dec, 2009 2 commits
  8. 24 Dec, 2009 2 commits
  9. 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
  10. 24 Dec, 2009 1 commit
  11. 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
  12. 21 Dec, 2009 1 commit
  13. 18 Dec, 2009 1 commit
  14. 24 Dec, 2009 4 commits
  15. 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
  16. 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
  17. 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
  18. 20 Dec, 2009 1 commit
  19. 18 Dec, 2009 1 commit