1. 02 Nov, 2011 1 commit
    • Alfranio Correia's avatar
      BUG#13337202 - REPLICATION PERFORMANCE DROP DUE TO "THE BINLOG MAY BE CORRUPTED" FLOOD · d1ba9b32
      Alfranio Correia authored
      In patch mysql-5.5:revno:3097.92.133, we made the gcc 4.6.1 compiler
      to stop complaining about the fact that binlog_can_be_corrupted was
      defined but not used. The fix consisted in checking the variable
      and printing a warning message.
      
      However, the fix caused a regression as a message was being printed
      out when there was no corrupted binary log causing performance
      problems and triggering users' suspicions when there was no need.
      
      In BUG#13337202, we do not print any message and use the variable
      in an "if" with an empty body to keep the compiler happy.
      d1ba9b32
  2. 26 Oct, 2011 6 commits
  3. 25 Oct, 2011 5 commits
    • Marko Mäkelä's avatar
      7ef002e9
    • Marko Mäkelä's avatar
      Fix results after Bug#12661768 fix. · e8d793f8
      Marko Mäkelä authored
      e8d793f8
    • Marko Mäkelä's avatar
      Bug#13002783 PARTIALLY UNINITIALIZED CASCADE UPDATE VECTOR · 013ba71d
      Marko Mäkelä authored
      In the ON UPDATE CASCADE clause of FOREIGN KEY constraints, the
      calculated update vector was not fully initialized. This bug was
      introduced in the InnoDB Plugin when implementing support for
      ROW_FORMAT=DYNAMIC.
      
      Additionally, the data type information was not initialized, but
      apparently it has never been needed in this case.  Nevertheless, it is
      not good programming practice to pass uninitialized values around.
      
      calc_row_difference(): Declare the update field uninitialized in
      Valgrind. Copy the data type information as well, except when the
      field is SQL NULL. In the built-in InnoDB, initialize
      ufield->extern_storage = FALSE (an initialization bug that had gone
      unnoticed this far). The InnoDB Plugin and later have this flag to
      dfield_t and have always initialized it properly.
      
      row_ins_cascade_calc_update_vec(): Reduce the scope of some
      pointers. Initialize orig_len. (This caused the bug in InnoDB Plugin
      and later.)
      
      row_ins_foreign_check_on_constraint(): Simplify a condition. Declare
      the update vector uninitialized.
      
      rb:771 approved by Jimmy Yang
      013ba71d
    • Vasil Dimov's avatar
    • Vasil Dimov's avatar
      Fix Bug#12661768 UPDATE IGNORE CRASHES SERVER IF TABLE IS INNODB AND IT IS · dce33740
      Vasil Dimov authored
      PARENT FOR OTHER ONE
      
      Do not try to lookup key_nr'th key in 'table' because there may not be such
      a key there. key_nr is the number of the key in the _child_ table name, not
      in the parent table.
      
      Instead just print the fields of the record that are covered by the first key
      defined on the parent table.
      
      This bug gets a better fix in MySQL 5.6, which is too risky for 5.1 and 5.5.
      
      Approved by:	Jon Olav Hauglid (via IM)
      dce33740
  4. 24 Oct, 2011 5 commits
  5. 23 Oct, 2011 1 commit
    • Dmitry Lenev's avatar
      Fix for bug #13116518 - "OPEN_TABLES() SHOULD NOT ALLOCATE AND FREE · a656ff83
      Dmitry Lenev authored
      NEW_FRM_MEM WITHOUT NEEDING TO".
      
      During the process of opening tables for a statement, we allocated
      memory which was used only during view loading even in cases when the
      statement didn't use any views. Such an unnecessary allocation (and
      corresponding freeing) might have caused significant performance
      overhead in some workloads. For example, it caused up to 15% slowdown
      in a simple stored routine calculating Fibonacci's numbers.
      
      This memory was pre-allocated as part of "new_frm_mem" MEM_ROOT
      initialization at the beginning of open_tables(). 
      
      This patch addresses this issue by turning off memory pre-allocation
      during initialization for this MEM_ROOT. Now, memory on this root
      will be allocated only at the point when the first .FRM for a view is 
      opened.
      
      The patch doesn't contain a test case since it is hard to test the
      performance improvements or the absence of memory allocation in our
      test framework.
      a656ff83
  6. 22 Oct, 2011 1 commit
  7. 21 Oct, 2011 7 commits
  8. 20 Oct, 2011 3 commits
    • Alexander Nozdrin's avatar
      Auto-merge from mysql-5.1-security. · 442ec56c
      Alexander Nozdrin authored
      442ec56c
    • Alexander Nozdrin's avatar
    • Sergey Vojtovich's avatar
      BUG#11757032 - 49030: OPTIMIZE TABLE BREAKS MYISAM TABLE WHEN · de8c70e7
      Sergey Vojtovich authored
                     USING MYISAM_USE_MMAP ON WINDOWS
      
      When OPTIMIZE/REPAIR TABLE is switching to new data file,
      old data file is removed while memory mapping is still
      active.
      
      With 5.1 implementation of nt_share_delete() it is not
      permitted to remove mmaped file.
      
      This fix disables memory mapping for mi_repair() operations.
      
      mysql-test/r/myisam.result:
        A test case for BUG#11757032.
      mysql-test/t/myisam.test:
        A test case for BUG#11757032.
      storage/myisam/ha_myisam.cc:
        mi_repair*() functions family use file I/O even if memory
        mapping is available.
        
        Since mixing mmap I/O and file I/O may cause various artifacts,
        memory mapping must be disabled.
      storage/myisam/mi_delete_all.c:
        Clean-up: do not attempt to remap file after truncate, since
        there is nothing to map.
      de8c70e7
  9. 19 Oct, 2011 7 commits
  10. 18 Oct, 2011 2 commits
  11. 17 Oct, 2011 2 commits
    • unknown's avatar
      BUG#12968567: mysql_plugin : incorrect return from bootstrap failure · 3c869a52
      unknown authored
      This patch corrects a defect whereby the bootstrap_server() method was
      returning 0 instead of the error code generated. The code has been changed to
      return the correct value returned from the bootstrap command.
      3c869a52
    • unknown's avatar
      BUG#12968815: mysql_plugin : disable requires plugin name but doesn't use it · d1846e3b
      unknown authored
      This patch corrects a defect in the building of the DELETE commands for
      disabling a plugin whereby only the original plugin data was deleted. If there
      were other plugins, the delete did not remove the rows. The code has been
      changed to remove all rows from the mysql.plugin table that were inserted when
      the plugin was loaded. The test has also been changed to correctly identify if
      all rows have been deleted.
      d1846e3b