1. 28 Nov, 2009 1 commit
  2. 27 Nov, 2009 1 commit
  3. 26 Nov, 2009 1 commit
  4. 24 Nov, 2009 1 commit
    • Luis Soares's avatar
      BUG#42150: binlog_start_comment.test failed: Error writing file 'UNOPENED' · 799333b5
      Luis Soares authored
      NOTE: backporting BUG#42150 into next-mr
            Includes latest Andrei's patch (see [2 Feb 18:40] Bugs System)
            and merge.test post-push fix (see [3 Feb 18:04] Bugs System)
      
      The reason of the bug appeared to be overreacting on absense of a
      binlog file although the file name had been presented in in the master
      binlog index file.
      By convention, there should have been only a warning printed and the rest of
      `reset master' logics completed.  This did not happen on windows
      due to incorrect value of my_errno returned from nt_share_delete().
            
      Fixed with correcting my_errno assignment in nt_share_delete() to be ENOENT in 
      he event of no binlog file. Some minor refactoring has been made.
      799333b5
  5. 22 Nov, 2009 1 commit
    • Luis Soares's avatar
      BUG#40611: MySQL cannot make a binary log after sequential number · 1d00d426
      Luis Soares authored
      beyond unsigned long.
      BUG#44779: binlog.binlog_max_extension may be causing failure on 
      next test in PB
                  
      NOTE1: this is the backport to next-mr.
      NOTE2: already includes patch for BUG#44779.
                  
      Binlog file extensions would turn into negative numbers once the
      variable used to hold the value reached maximum for signed
      long. Consequently, incrementing value to the next (negative) number
      would lead to .000000 extension, causing the server to fail.
                              
      This patch addresses this issue by not allowing negative extensions
      and by returning an error on find_uniq_filename, when the limit is
      reached. Additionally, warnings are printed to the error log when the
      limit is approaching. FLUSH LOGS will also report warnings to the
      user, if the extension number has reached the limit. The limit has been
      set to 0x7FFFFFFF as the maximum.
      1d00d426
  6. 20 Nov, 2009 1 commit
    • Andrei Elkin's avatar
      Bug #48463 backporting from 6.0-rpl to celosia a set of bugs · 3a76c32c
      Andrei Elkin authored
      The mentioned on the bug report set of bugs fixes have not be pushed to the main trees.
      
      Fixed with extracting commits done to 6.0-rpl tree and applying them to the main 5.1.
      Notes.
      1. part of changes - the mtr's specific - were packported to the main 5.0 tree for mtr v1
         as http://lists.mysql.com/commits/46562
         However, there is no that fix anymore in the mtr v2. (This fact was mailed to mtr maintaining
         people).
      
      2. Bug@36929  crash in kill_zombie_dump_threads-> THD::awake() with replication tests
         is not backported because the base code of the patch is libevent and that was removed
         from the main trees due to its instability.
      3a76c32c
  7. 16 Nov, 2009 1 commit
    • Luis Soares's avatar
      BUG#48048: Deprecated constructs need removal in Betony · 20e7e3a6
      Luis Soares authored
      Post-push fix: Removed MTRv1 arguments according to the
      original patch. Although there is a version check, the patch
      was pushed to a 5.1 GA staging tree, while the version check 
      considers version 5.2. This makes the deprecated parameters 
      to be used, despite the fact that they are not valid anymore.
      
      Part of MTRv1 is currently used in RQG semisync test, and this
      was causing the test to fail on slave startup.
      
      It should be safe to uncomment when merging up to celosia.
      20e7e3a6
  8. 13 Nov, 2009 3 commits
  9. 11 Nov, 2009 1 commit
  10. 06 Nov, 2009 1 commit
  11. 04 Nov, 2009 1 commit
    • Luis Soares's avatar
      BUG#48048: Deprecated constructs need removal in Betony · 6e068a9c
      Luis Soares authored
      NOTE: Backport of:
      
      bzr log -r revid:sp1r-serg@sergbook.mysql.com-20070505200319-38337
      ------------------------------------------------------------
      revno: 2469.263.4
      committer: serg@sergbook.mysql.com
      timestamp: Sat 2007-05-05 13:03:19 -0700
      message:
        Removing deprecated features:
        --master-XXX command-line options
        log_bin_trust_routine_creators
        table_type
        BACKUP TABLE ...
        RESTORE TABLE ...
        SHOW PLUGIN
        LOAD TABLE ... FROM MASTER
        LOAD DATA FROM MASTER
        SHOW INNODB STATUS
        SHOW MUTEX STATUS
        SHOW TABLE TYPES
        ... TIMESTAMP(N)
        ... TYPE=engine
        
        RESET SLAVE don't reset connection parameters anymore
        LOAD DATA: check opt_secure_file_priv before access(filename)
        improved WARN_DEPRECATED macro
      6e068a9c
  12. 27 Oct, 2009 1 commit
  13. 23 Oct, 2009 5 commits
  14. 20 Oct, 2009 2 commits
    • Bjorn Munch's avatar
      merge 48149 · 684b1d39
      Bjorn Munch authored
      684b1d39
    • 's avatar
      Bug#13963 SHOW SLAVE HOSTS is unreliable · d17245e7
      authored
            
            Before the patch, slaves only appear in the output of SHOW SLAVE HOSTS 
            when report-host option is set. If an expected slave does not appear in  
            the list, nobody knows whether the slave does not connect or has started
            without the "report-host" option. The output also contains a strange  
            field "Rpl_recovery_rank" which has never been implemented and the manual 
            of MySQL5.4 declares that the field has been removed from MySQL5.4.
                                              
            This patch is done with these,
            According to the manual of MySQL5.4, "Rpl_recovery_rank" is removed.
            Slaves will register themselves to master no matter if report_host option is set
            or not. When slaves are registering themselves, their Server_ids, report_host
            and other information are together sent to master. Sever_ids are never null 
            and is unique in one replication group. Slaves always can be identified with  
            different Server_ids no matter if report_host exists.
      d17245e7
  15. 19 Oct, 2009 2 commits
  16. 18 Oct, 2009 2 commits
  17. 17 Oct, 2009 1 commit
  18. 16 Oct, 2009 10 commits
  19. 15 Oct, 2009 4 commits