1. 09 Jul, 2010 1 commit
  2. 08 Jul, 2010 9 commits
    • Davi Arnaut's avatar
      Bug#34043: Server loops excessively in _checkchunk() when safemalloc is enabled · 3143a4dc
      Davi Arnaut authored
      Essentially, the problem is that safemalloc is excruciatingly
      slow as it checks all allocated blocks for overrun at each
      memory management primitive, yielding a almost exponential
      slowdown for the memory management functions (malloc, realloc,
      free). The overrun check basically consists of verifying some
      bytes of a block for certain magic keys, which catches some
      simple forms of overrun. Another minor problem is violation
      of aliasing rules and that its own internal list of blocks
      is prone to corruption.
      
      Another issue with safemalloc is rather the maintenance cost
      as the tool has a significant impact on the server code.
      Given the magnitude of memory debuggers available nowadays,
      especially those that are provided with the platform malloc
      implementation, maintenance of a in-house and largely obsolete
      memory debugger becomes a burden that is not worth the effort
      due to its slowness and lack of support for detecting more
      common forms of heap corruption.
      
      Since there are third-party tools that can provide the same
      functionality at a lower or comparable performance cost, the
      solution is to simply remove safemalloc. Third-party tools
      can provide the same functionality at a lower or comparable
      performance cost. 
      
      The removal of safemalloc also allows a simplification of the
      malloc wrappers, removing quite a bit of kludge: redefinition
      of my_malloc, my_free and the removal of the unused second
      argument of my_free. Since free() always check whether the
      supplied pointer is null, redudant checks are also removed.
      
      Also, this patch adds unit testing for my_malloc and moves
      my_realloc implementation into the same file as the other
      memory allocation primitives.
      
      client/mysqldump.c:
        Pass my_free directly as its signature is compatible with the
        callback type -- which wasn't the case for free_table_ent.
      3143a4dc
    • Luis Soares's avatar
      Revert patch for BUG#54744. · c5228283
      Luis Soares authored
      c5228283
    • Marc Alff's avatar
      Fixed headers in include/mysql/psi · 9fbee1a5
      Marc Alff authored
      9fbee1a5
    • Olav Sandstaa's avatar
      Backporting of jorgen.loland@sun.com-20100618093212-lifp1psig3hbj6jj · 07b54ddc
      Olav Sandstaa authored
      from mysql-next-mr-opt-backporting.
      
      Bug#54515: Crash in opt_range.cc::get_best_group_min_max on 
                 SELECT from VIEW with GROUP BY
            
      When handling the grouping items in get_best_group_min_max, the
      items need to be of type Item_field. In this bug, an ASSERT 
      triggered because the item used for grouping was an 
      Item_direct_view_ref (i.e., the group column is from a view). 
      The fix is to get the real_item since Item_ref* pointing to 
      Item_field is ok.
      
      mysql-test/r/select.result:
        Add test for BUG#54515
      mysql-test/t/select.test:
        Add test for BUG#54515
      sql/opt_range.cc:
        Get the real_item() when processing grouping items in 
        get_best_group_min_max.
      07b54ddc
    • Guilhem Bichot's avatar
      backport of guilhem@mysql.com-20100628140739-i9vy8ugxp1v5aspb · d1bf703c
      Guilhem Bichot authored
      from next-mr-bugfixing:
      BUG#54682 "set sql_select_limit=0 does not work"; let SQL_SELECT_LIMIT=0
      work like it does in 5.1.
      
      
      mysql-test/suite/sys_vars/r/sql_select_limit_func.result:
        before the fix, the SET would emit a warning (0 being rounded up to 1)
        and SELECTs would return one row.
      sql/sys_vars.cc:
        0 is allowed, it means an implicit LIMIT 0 (i.e. no rows returned)
      d1bf703c
    • Luis Soares's avatar
      9c8ddbcd
    • Luis Soares's avatar
      906051fc
    • Luis Soares's avatar
      39a0c2e6
    • Luis Soares's avatar
      eb1c3e85
  3. 07 Jul, 2010 3 commits
  4. 06 Jul, 2010 3 commits
    • Luis Soares's avatar
      BUG#54744: valgrind reports leak for mysqlbinlog · 2cd4044d
      Luis Soares authored
      The server was not cleaning up dbug allocated memory before
      exiting. This is not a real problem, as this memory would be
      deallocated anyway. Nonetheless, we improve the mysqlbinlog exit
      procedure, wrt to memory book-keeping, when no parameter is
      given.
      
      To fix this, we deploy a call to my_thread_end() before the
      thread exits, which will also free pending dbug related allocated
      blocks.
      2cd4044d
    • Davi Arnaut's avatar
      Bug#54783: optimize table crashes with invalid timestamp default · da6fb417
      Davi Arnaut authored
                 value and NO_ZERO_DATE
      
      The problem was that a older version of the error path for a
      failed admin statement relied upon a few error conditions being
      met in order to access a table handler, the first one being that
      the table object pointer was not NULL. Probably due to chance,
      in all cases a table object was closed but the reference wasn't
      reset, the other conditions didn't evaluate to true. With the
      addition of a new check on the error path, the handler started
      being dereferenced whenever it was not reset to NULL, causing
      problems for code paths which closed the table but didn't reset
      the reference.
      
      The solution is to reset the reference whenever a admin statement
      fails and the tables are closed.
      
      mysql-test/r/partition_innodb.result:
        Add test case result for Bug#54783
      mysql-test/t/partition_innodb.test:
        Add test case for Bug#54783
      sql/sql_table.cc:
        In case table recreate failed, set a appropriate result code.
        Reset reference to a closed table object, otherwise the error
        path might attempt to access it.
      da6fb417
    • Alexander Nozdrin's avatar
      1850ede4
  5. 05 Jul, 2010 5 commits
  6. 04 Jul, 2010 1 commit
  7. 02 Jul, 2010 2 commits
  8. 01 Jul, 2010 1 commit
    • Luis Soares's avatar
      BUG#54925: Assertion `query_arg && mysql_bin_log.is_open()' on · 4ae61044
      Luis Soares authored
      DROP TEMP TABLE
      
      Cset: alfranio.correia@sun.com-20100420091043-4i6ouzozb34hvzhb
      introduced a change that made drop temporary table to be always
      logged if current statement log format was set to row. This is
      fine. However, logging operations, for a "DROP TABLE" statement
      in mysql_rm_table_part2, are not protected by first checking if
      the mysql_bin_log is open before proceeding to the actual
      logging. They only check the dont_log_query variable. This was
      actually uncovered by the aforementioned cset and not introduced
      by it.
      
      We fix this by extending the condition used in the "if" that
      wraps logging operations in mysql_rm_table_part2.
      4ae61044
  9. 30 Jun, 2010 6 commits
    • Alfranio Correia's avatar
    • Alfranio Correia's avatar
      WL#5344 · 372556bd
      Alfranio Correia authored
      372556bd
    • Alfranio Correia's avatar
    • Alfranio Correia's avatar
      BUG#53259 Unsafe statement binlogged in statement format w/MyIsam temp tables · 846870d8
      Alfranio Correia authored
      BUG#54872 MBR: replication failure caused by using tmp table inside transaction 
            
      Changed criteria to classify a statement as unsafe in order to reduce the
      number of spurious warnings. So a statement is classified as unsafe when
      there is on-going transaction at any point of the execution if:
      
      1. The mixed statement is about to update a transactional table and
      a non-transactional table.
      
      2. The mixed statement is about to update a temporary transactional
      table and a non-transactional table.
            
      3. The mixed statement is about to update a transactional table and
      read from a non-transactional table.
      
      4. The mixed statement is about to update a temporary transactional
      table and read from a non-transactional table.
      
      5. The mixed statement is about to update a non-transactional table
      and read from a transactional table when the isolation level is
      lower than repeatable read.
      
      After updating a transactional table if:
      
      6. The mixed statement is about to update a non-transactional table
      and read from a temporary transactional table.
       
      7. The mixed statement is about to update a non-transactional table
       and read from a temporary transactional table.
      
      8. The mixed statement is about to update a non-transactionala table
         and read from a temporary non-transactional table.
           
      9. The mixed statement is about to update a temporary non-transactional
      table and update a non-transactional table.
           
      10. The mixed statement is about to update a temporary non-transactional
      table and read from a non-transactional table.
           
      11. A statement is about to update a non-transactional table and the
      option variables.binlog_direct_non_trans_update is OFF.
      
      The reason for this is that locks acquired may not protected a concurrent
      transaction of interfering in the current execution and by consequence in
      the result. So the patch reduced the number of spurious unsafe warnings.
      
      Besides we fixed a regression caused by BUG#51894, which makes temporary
      tables to go into the trx-cache if there is an on-going transaction. In
      MIXED mode, the patch for BUG#51894 ignores that the trx-cache may have
      updates to temporary non-transactional tables that must be written to the
      binary log while rolling back the transaction.
            
      So we fix this problem by writing the content of the trx-cache to the
      binary log while rolling back a transaction if a non-transactional
      temporary table was updated and the binary logging format is MIXED.
      846870d8
    • Vladislav Vaintroub's avatar
      Bug #52850: mysqld-debug.pdb doesn't match · 941e13f1
      Vladislav Vaintroub authored
      mysqld-debug.exe in 5.5.3 on windows
      
      Fix:
      
      - Do not rename PDB, install mysqld.pdb matching 
      mysqld-debug.exe into bin\debug subdirectory
      
      - Stack tracing code will now additionally look in 
      debug subdirectory of the application directory 
      for debug symbols.
      
      - Small cleanup in stacktracing code: link with 
      dbghelp rather than load functions dynamically 
      at runtime, since dbghelp.dll is always present.
      
      - Install debug binaries with WiX
      
      cmake/install_macros.cmake:
        Add optional COMPONENT and PDB_DESTINATION 
        to INSTALL_DEBUG_TARGET
      mysys/stacktrace.c:
        If binary is build with DBUG, also look in debug subdirectory
        of  executable directory. Packaging will put some PDBs there
        (e.g bin\mysqld-debug.exe will have corresponding pdb in 
        bin\debug)
        
        Also some cleanup: do not load dbghelp dynamically, instead
        link with it. dbghelp is present on all Windows starting with 
        XP.
      packaging/WiX/CPackWixConfig.cmake:
        Install debug binaries
      sql/CMakeLists.txt:
        Do not rename PDB for mysqld-debug.exe, install it in debug subdirectory
      941e13f1
    • Alexander Nozdrin's avatar
  10. 29 Jun, 2010 1 commit
    • Luis Soares's avatar
      BUG#54842: DROP TEMPORARY TABLE not binlogged after manual · 60bc62d2
      Luis Soares authored
      switching binlog format to ROW
      
      BUG 52616 fixed the case which the user would switch from STMT to
      ROW binlog format, but the server would silently ignore it. After
      that fix thd->is_current_stmt_binlog_format_row() reports correct
      value at logging time and events are logged in ROW (as expected)
      instead of STMT as they were previously and wrongly logged.
      
      However, the fix was only partially complete, because on
      disconnect, at THD cleanup, the implicit logging of temporary
      tables is conditionally performed. If the binlog_format==ROW and
      thd->is_current_stmt_binlog_format_row() is true then DROPs are
      not logged. Given that the user can switch from STMT to ROW, this
      is wrong because the server cannot tell, just by relying on the
      ROW binlog format, that the tables have been dropped before. This
      is effectively similar to the MIXED scenario when a switch from
      STMT to ROW is triggered.
      
      We fix this by removing this condition from
      close_temporary_tables.
      
      mysql-test/extra/binlog_tests/drop_temp_table.test:
        Added binlog test case.
      mysql-test/suite/binlog/r/binlog_row_drop_tmp_tbl.result:
        Result changes because:
        - there is a missing drop on three temporary tables
        - it now contains results for the test added
      mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result:
        Result now contains the implicit drop for the temporary table.
      mysql-test/suite/binlog/r/binlog_stm_drop_tmp_tbl.result:
        Result file changed because it now contains results for added
        test case.
      mysql-test/suite/rpl/r/rpl_drop_temp.result:
        Result file changed because it now contains results for added
        test case.
      mysql-test/suite/rpl/t/rpl_drop_temp.test:
        Added replication test case.
      sql/sql_base.cc:
        Removed the condition that would make the server to skip
        logging implicit drops when ROW binary log format mode was 
        in use.
        Additionally, deployed DBUG_ENTER/RETURN macros.
      60bc62d2
  11. 28 Jun, 2010 2 commits
  12. 26 Jun, 2010 2 commits
  13. 25 Jun, 2010 3 commits
    • Gleb Shchepa's avatar
      5fe5b5f4
    • Alexander Nozdrin's avatar
      Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111 · 5879001b
      Alexander Nozdrin authored
         Bug#47633 - assert in ha_myisammrg::info during OPTIMIZE
       
         The server crashed on an attempt to optimize a MERGE table with
         non-existent child table.
       
         mysql_admin_table() relied on the table to be successfully open
         if a table object had been allocated.
       
         Changed code to check return value of the open function before
         calling a handler:: function on it.
      
      mysql-test/r/merge.result:
        Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111
            Bug#47633 - assert in ha_myisammrg::info during OPTIMIZE
            Updated result file.
      mysql-test/t/merge.test:
        Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111
            Bug#47633 - assert in ha_myisammrg::info during OPTIMIZE
            Changed tests to respect changed TEMPORARY MERGE locking (unrelated).
            Changed tests to respect changed CREATE TABLE ... LIKE (unrelated).
            Changed tests to respect that no new tables can be created
            under LOCK TABLE (unrelated).
            Added test for Bug#47633.
        Changed error numbers to symbolic names.
        Added test for child locking for ALTER under LOCK TABLE.
        
        Since Bug 36171 is not pushed yet, not the whole patch has been backported.
      mysys/my_delete.c:
        Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111
            Bug#47633 - assert in ha_myisammrg::info during OPTIMIZE
            Fixed error reporting.
            Fixed indentation.
      mysys/my_mmap.c:
        Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111
            Bug#47633 - assert in ha_myisammrg::info during OPTIMIZE
            Added DBUG.
      sql/item_func.cc:
        Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111
        Added Debug Sync point, required by merge_sync.test.
      sql/sql_table.cc:
        Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111
            Bug#47633 - assert in ha_myisammrg::info during OPTIMIZE
            Do not call handler:: functions if the table was not opened
            successfully.
        Added Debug Sync point, required by merge_sync.test.
      storage/myisam/mi_check.c:
        Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111
            Bug#47633 - assert in ha_myisammrg::info during OPTIMIZE
            Unmap memory before exchanging data files. Needed on Windows.
      storage/myisammrg/ha_myisammrg.cc:
        Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111
        Added Debug Sync point, required by merge_sync.test.
        
        merge_sync.test will be introduced by a patch for Bug 36171,
        which is not pushed yet.
      5879001b
    • Jon Olav Hauglid's avatar
      Bug #50124 Rpl failure on DROP table with concurrent txn/non-txn · 8a8c5c35
      Jon Olav Hauglid authored
                 DML flow and SAVEPOINT
      
      The problem was that replication could break if a transaction involving
      both transactional and non-transactional tables was rolled back to a
      savepoint. It broke if a concurrent connection tried to drop a
      transactional table which was locked after the savepoint was set.
      This DROP TABLE completed when ROLLBACK TO SAVEPOINT was executed as the
      lock on the table was dropped by the transaction. When the slave later
      tried to apply the binlog, it would fail as the table would already
      have been dropped.
      
      The reason for the problem is that transactions involving both
      transactional and non-transactional tables are written fully to the
      binlog during ROLLBACK TO SAVEPOINT. At the same time, metadata locks
      acquired after a savepoint, were released during ROLLBACK TO SAVEPOINT.
      This allowed a second connection to drop a table only used between
      SAVEPOINT and ROLLBACK TO SAVEPOINT. Which caused the transaction binlog
      to refer to a non-existing table when it was written during ROLLBACK
      TO SAVEPOINT.
      
      This patch fixes the problem by not releasing metadata locks when
      ROLLBACK TO SAVEPOINT is executed if binlogging is enabled.
      8a8c5c35
  14. 24 Jun, 2010 1 commit
    • Luis Soares's avatar
      BUG#54509: rpl_show_slave_running crashes the server sporadically · f24e98f7
      Luis Soares authored
      Problem: SQL and IO thread were racing for the IO_CACHE. The former to
      flush it, the latter to close it. In some cases this would cause the
      SQL thread to lock an invalid IO_CACHE mutex (it had been destroyed by
      IO thread). This would happen when SQL thread was initializing the
      master.info
      
      Solution: We solve this by locking the log and checking if it is
      hot. If it is we keep the log while seeking. Otherwise we release it
      right away, because a log can get from hot to cold, but not from cold
      to hot.
      f24e98f7