1. 07 Jul, 2010 3 commits
  2. 06 Jul, 2010 2 commits
    • 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
  3. 05 Jul, 2010 5 commits
  4. 04 Jul, 2010 1 commit
  5. 02 Jul, 2010 2 commits
  6. 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
  7. 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
  8. 28 Jun, 2010 2 commits
  9. 26 Jun, 2010 2 commits
  10. 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
  11. 23 Jun, 2010 9 commits
  12. 22 Jun, 2010 4 commits
    • Gleb Shchepa's avatar
      Bug #30584: delete with order by and limit clauses does not · 5070029c
      Gleb Shchepa authored
                  use limit efficiently
      Bug #36569: UPDATE ... WHERE ... ORDER BY... always does a
                  filesort even if not required
      
      Also two bugs reported after QA review (before the commit
      of bugs above to public trees, no documentation needed):
      
      Bug #53737: Performance regressions after applying patch
                  for bug 36569
      Bug #53742: UPDATEs have no effect after applying patch
                  for bug 36569
      
      
      Execution of single-table UPDATE and DELETE statements did not use the 
      same optimizer as was used in the compilation of SELECT statements. 
      Instead, it had an optimizer of its own that did not take into account 
      that you can omit sorting by retrieving rows using an index.
      
      Extra optimization has been added: when applicable, single-table 
      UPDATE/DELETE statements use an existing index instead of filesort. A 
      corresponding SELECT query would do the former.
      
      Also handling of the DESC ordering expression has been added when
      reverse index scan is applicable.
      
      From now on most single table UPDATE and DELETE statements show the 
      same disk access patterns as the corresponding SELECT query. We verify 
      this by comparing the result of SHOW STATUS LIKE 'Sort%
      
      Currently the get_index_for_order function 
      a) checks quick select index (if any) for compatibility with the
         ORDER expression list or
      b) chooses the cheapest available compatible index, but only if 
         the index scan is cheaper than filesort.
      Second way is implemented by the new test_if_cheaper_ordering
      function (extracted part the test_if_skip_sort_order()).
      
      
      
      mysql-test/r/log_state.result:
        Updated result for optimized query, bug #36569.
      mysql-test/r/single_delete_update.result:
        Test case for bug #30584, bug #36569 and bug #53742.
      mysql-test/r/update.result:
        Updated result for optimized query, bug #30584.
        Note:
        "Handler_read_last 1" omitted, see bug 52312:
        lost Handler_read_last status variable.
      mysql-test/t/single_delete_update.test:
        Test case for bug #30584, bug #36569 and bug #53742.
      sql/opt_range.cc:
        Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
                                always does a filesort even if not required
        
        * get_index_for_order() has been rewritten entirely and moved
          to sql_select.cc
        
        New QUICK_RANGE_SELECT::make_reverse method has been added.
      sql/opt_range.h:
        Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
                                always does a filesort even if not required
        
        * get_index_for_order() has been rewritten entirely and moved
          to sql_select.cc
        
        New functions:
        * QUICK_SELECT_I::make_reverse()
        * SQL_SELECT::set_quick()
      sql/records.cc:
        Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
                                always does a filesort even if not required
        
        * init_read_record_idx() has been modified to allow reverse index scan
        
        New functions:
        * rr_index_last()
        * rr_index_desc()
      sql/records.h:
        Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
                                always does a filesort even if not required
        
        init_read_record_idx() has been modified to allow reverse index scan
      sql/sql_delete.cc:
        Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
                                always does a filesort even if not required
            
        mysql_delete: an optimization has been added to skip
        unnecessary sorting with ORDER BY clause where select
        result ordering is acceptable.
      sql/sql_select.cc:
        Bug #30584, bug #36569, bug #53737, bug #53742:
          UPDATE/DELETE ... WHERE ... ORDER BY...  always does a filesort
          even if not required
            
        The const_expression_in_where function has been modified
        to accept both Item and Field pointers.
        
        New functions:
        * get_index_for_order()
        * test_if_cheaper_ordering() has been extracted from
          test_if_skip_sort_order() to share with get_index_for_order()
        * simple_remove_const()
      sql/sql_select.h:
        Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
                                always does a filesort even if not required
            
        New functions:
        * test_if_cheaper_ordering()
        * simple_remove_const()
        * get_index_for_order()
      sql/sql_update.cc:
        Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
                                always does a filesort even if not required
            
        mysql_update: an optimization has been added to skip
        unnecessary sorting with ORDER BY clause where a select
        result ordering is acceptable.
      sql/table.cc:
        Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
                                always does a filesort even if not required
        
        New functions:
        * TABLE::update_const_key_parts()
        * is_simple_order()
      sql/table.h:
        Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY...
                                always does a filesort even if not required
        
        New functions:
        * TABLE::update_const_key_parts()
        * is_simple_order()
      5070029c
    • Vladislav Vaintroub's avatar
      Fix syntax error (missing space in SET command), that effectively prevents... · 6302cb60
      Vladislav Vaintroub authored
      Fix syntax error (missing space in SET command),  that effectively prevents mysqld from being build with SSL.
      6302cb60
    • Vladislav Vaintroub's avatar
      Fix ~1000 warnings class/struct mismatch. · 3b127383
      Vladislav Vaintroub authored
      Handle this warning in the future as error, this will prevent pushing to main trees.
      3b127383
    • Alexander Nozdrin's avatar
      Auto-merge (empty) from mysql-trunk. · 9dfe5eb1
      Alexander Nozdrin authored
      9dfe5eb1