1. 08 Jul, 2010 1 commit
  2. 07 Jul, 2010 3 commits
  3. 06 Jul, 2010 3 commits
    • Luis Soares's avatar
      BUG#54744: valgrind reports leak for mysqlbinlog · ba4c3b07
      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.
      ba4c3b07
    • Davi Arnaut's avatar
      Bug#54783: optimize table crashes with invalid timestamp default · 07a9c082
      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.
      07a9c082
    • Alexander Nozdrin's avatar
      bf4a5d96
  4. 05 Jul, 2010 5 commits
  5. 04 Jul, 2010 1 commit
  6. 02 Jul, 2010 2 commits
  7. 30 Jun, 2010 6 commits
    • Alfranio Correia's avatar
    • Alfranio Correia's avatar
      WL#5344 · 34664b6a
      Alfranio Correia authored
      34664b6a
    • Alfranio Correia's avatar
    • Alfranio Correia's avatar
      BUG#53259 Unsafe statement binlogged in statement format w/MyIsam temp tables · e662b51e
      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.
      e662b51e
    • Vladislav Vaintroub's avatar
      Bug #52850: mysqld-debug.pdb doesn't match · 41d832d1
      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
      41d832d1
    • Alexander Nozdrin's avatar
  8. 29 Jun, 2010 1 commit
    • Luis Soares's avatar
      BUG#54842: DROP TEMPORARY TABLE not binlogged after manual · bf261cdb
      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.
      bf261cdb
  9. 28 Jun, 2010 2 commits
  10. 26 Jun, 2010 2 commits
  11. 25 Jun, 2010 3 commits
    • Gleb Shchepa's avatar
      6941da51
    • Alexander Nozdrin's avatar
      Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111 · 514b9b25
      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.
      514b9b25
    • Jon Olav Hauglid's avatar
      Bug #50124 Rpl failure on DROP table with concurrent txn/non-txn · 80af1318
      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.
      80af1318
  12. 23 Jun, 2010 9 commits
  13. 22 Jun, 2010 2 commits
    • Gleb Shchepa's avatar
      Bug #30584: delete with order by and limit clauses does not · da4d2327
      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()).
      da4d2327
    • Vladislav Vaintroub's avatar
      Fix syntax error (missing space in SET command), that effectively prevents... · a4baec5c
      Vladislav Vaintroub authored
      Fix syntax error (missing space in SET command),  that effectively prevents mysqld from being build with SSL.
      a4baec5c