1. 29 Sep, 2011 3 commits
    • Marko Mäkelä's avatar
      Update the German error message translations (by Stefan Hinz) · 0c775ea9
      Marko Mäkelä authored
      and fix some Swedish too.
      0c775ea9
    • Andrei Elkin's avatar
      Bug#11747416 : 32228 A disk full makes binary log corrupt · 593c9457
      Andrei Elkin authored
      Binary log of master can get a partially logged event if the server
      runs out of disk space and, while waiting for some space to be freed,
      is shut down (or crashes). If the server is not stopped, it will just
      wait endlessly for space to be freed, thus no partial event anomaly
      occurs.  The restarted master server has had a dubious policy to send
      the incomplete event to slave which it apparently can't handle.
      Although an error was printed out the fact of sending with unclear
      error message is a source of confusion.
      Actually the problem of presence an incomplete event in the binary log
      was already fixed by WL 5493 (which was merged to our current trunk
      branch, major version 5.6). The fix makes the server truncate the
      binary log on server restart and recovery.
      
      However 5.5 master can't do that. So the current issue is a problem of
      sending incomplete events to the slave by 5.5 master.
      
      It is fixed in this patch by changing the policy so that only complete
      events are pushed by the dump thread to the IO thread. In addition,
      the error text that master sends to the slave when an incomplete event
      is found, now states that incomplete event may have been caused by an
      out-of-disk space situation and provides coordinates of
      the first and the last event bytes read.
      
      
      mysql-test/std_data/bug11747416_32228_binlog.000001:
        a binlog is added with the last event written partly.
      mysql-test/suite/rpl/r/rpl_cant_read_event_incident.result:
        new result file is added.
      mysql-test/suite/rpl/r/rpl_log_pos.result:
        results updated.
      mysql-test/suite/rpl/r/rpl_manual_change_index_file.result:
        results updated.
      mysql-test/suite/rpl/r/rpl_packet.result:
        results updated.
      mysql-test/suite/rpl/t/rpl_cant_read_event_incident.test:
        regression test for bug#11747416 : 32228 A disk full makes binary log corrupt
        is added.
      sql/share/errmsg-utf8.txt:
        Increasing the explanatory part of ER_MASTER_FATAL_ERROR_READING_BINLOG error message twice
        in order to fit to the updated version which carries some more info.
      sql/sql_repl.cc:
        Error text indicating a failure of reading from binlog that master delivers to the slave 
        is made more clear;
        A policy to regard a partial event to send it out to the slave anyway is removed.
      593c9457
    • Rohit Kalhans's avatar
      BUG#11758262 - 50439: MARK INSERT...SEL...ON DUP KEY UPD,REPLACE...SEL,CREATE...[IGN|REPL] SEL · 586c0c0e
      Rohit Kalhans authored
      Problem: The following statements can cause the slave to go out of sync 
      if logged in statement format: 
      INSERT IGNORE...SELECT 
      INSERT ... SELECT ... ON DUPLICATE KEY UPDATE 
      REPLACE ... SELECT 
      UPDATE IGNORE :
      CREATE ... IGNORE SELECT 
      CREATE ... REPLACE SELECT  
                 
      Background: Since the order of the rows returned by the SELECT 
      statement or otherwise may differ on master and slave, therefore
      the above statements may cuase the salve to go out of sync with
      the master. 
            
      Fix:
      Issue a warning when statements like the above are exectued and 
      the bin-logging format is statement. If the logging format is mixed,
      use row based logging. Marking a statement as unsafe has been 
      done in the sql/sql_parse.cc instead of sql/sql_yacc.cc, because while
      parsing for a token has been done we cannot be sure if the parsing
      of the other tokens has been done as well.
            
      Six new warning  messages has been added for each unsafe statement. 
            
      binlog.binlog_unsafe.test has been updated to incoporate these additional unsafe statments.
      
      
      ******
      BUG#11758262 - 50439: MARK INSERT...SEL...ON DUP KEY UPD,REPLACE...SEL,CREATE...[IGN|REPL] SEL 
      Problem: The following statements can cause the slave to go out of sync 
      if logged in statement format: 
      INSERT IGNORE...SELECT 
      INSERT ... SELECT ... ON DUPLICATE KEY UPDATE 
      REPLACE ... SELECT 
      UPDATE IGNORE :
      CREATE ... IGNORE SELECT 
      CREATE ... REPLACE SELECT  
                 
      Background: Since the order of the rows returned by the SELECT 
      statement or otherwise may differ on master and slave, therefore
      the above statements may cuase the salve to go out of sync with
      the master. 
            
      Fix:
      Issue a warning when statements like the above are exectued and 
      the bin-logging format is statement. If the logging format is mixed,
      use row based logging. Marking a statement as unsafe has been 
      done in the sql/sql_parse.cc instead of sql/sql_yacc.cc, because while
      parsing for a token has been done we cannot be sure if the parsing
      of the other tokens has been done as well.
            
      Six new warning  messages has been added for each unsafe statement. 
            
      binlog.binlog_unsafe.test has been updated to incoporate these additional unsafe statments.
      
      
      
      mysql-test/extra/rpl_tests/rpl_insert_duplicate.test:
        Test removed: Added the test to rpl.rpl_insert_ignore.test
        
        
        
        ******
        Test removed: the test is redundant as the same is being tested in rpl.rpl_insert_ignore.
      mysql-test/extra/rpl_tests/rpl_insert_id.test:
        Warnings disabled for the unsafe statements.
      mysql-test/extra/rpl_tests/rpl_insert_ignore.test:
        1. Disabled warnings while  for unsafe statements
        2. As INSERT...IGNORE is an unsafe statement, an insert ignore not changing any rows, 
        will not be logged in the binary log, in the ROW and MIXED modes. It will however be logged
        in STATEMENT mode.
      mysql-test/r/commit_1innodb.result:
        updated result file
        
        
        
        ******
        updated result file
      mysql-test/suite/binlog/r/binlog_stm_blackhole.result:
        Updated result file.
      mysql-test/suite/binlog/r/binlog_unsafe.result:
        updated result file
      mysql-test/suite/binlog/t/binlog_unsafe.test:
         added tests for the statements marked as unsafe.
      mysql-test/suite/rpl/r/rpl_insert_duplicate.result:
        File Removed :Result file of rpl_insert_duplicate, which has been removed.
      mysql-test/suite/rpl/r/rpl_insert_ignore.result:
        Added the content of rpl.rpl_insert_duplicate here.
      mysql-test/suite/rpl/r/rpl_insert_select.result:
        Result file removed as the corresponding test has beenn removed.
      mysql-test/suite/rpl/r/rpl_known_bugs_detection.result:
        Updated result file.
      mysql-test/suite/rpl/t/rpl_insert_duplicate.test:
        File Removed: this was a wrapper for rpl.rpl_insert_duplicate.test, which has been removed.
      mysql-test/suite/rpl/t/rpl_insert_select.test:
        File Removed: This test became redundant after this fix, This test showed how INSERT IGNORE...SELECT break replication, which has been handled in this fix.
      mysql-test/suite/rpl/t/rpl_known_bugs_detection.test:
        Since all the tests are statement based bugs are being tested, having mixed format
        forces the event to be written in row format. When the statement and causes the
        test to fail as certain known bugs do not occur when the even is logged in row format.
      sql/share/errmsg-utf8.txt:
        added 6 new Warning messages.
        
        
        
        ******
        added 6 new Warning messages.
      sql/sql_lex.cc:
        Added 6 new error Identifier [ER_BINLOG_STMT_UNSAFEE_*]
      sql/sql_lex.h:
        Added 6 new BINLOG_STMT_UNSAFE_* enums to identify the type of unsafe statement dealt with in this bug.
        
        
        ******
        Added 6 new BINLOG_STMT_UNSAFE_* enums to identify the type of unsafe statement dealt with in this bug.
      sql/sql_parse.cc:
        added check for specific queries and marked them as unsafe.
        
        
        ******
        added check for specific queries and marked them as unsafe.
      586c0c0e
  2. 28 Sep, 2011 2 commits
  3. 27 Sep, 2011 3 commits
  4. 26 Sep, 2011 10 commits
    • Tor Didriksen's avatar
      local merge · 9cc04425
      Tor Didriksen authored
      9cc04425
    • Tor Didriksen's avatar
      Bug#12985030 SIMPLE QUERY WITH DECIMAL NUMBERS LEAKS MEMORY · 0b706e54
      Tor Didriksen authored
      Re-write the test, to make pushbuild green.
      Workaraound for broken pow() function on:
      SunOS tyr40 5.10 Generic_127112-05 i86pc i386 i86pc
      
      (dbx) where
      current thread: t@1
      =>[1] Item_func_pow::val_real(this = 0x238af20) (optimized), at 0xaa8d13 (line ~1980) in "item_func.cc"
      
      (dbx) print pow(1.01, 1.0)
      pow(1.01, 1) = 1.01
      (dbx) print pow(1.01, 10.0)
      pow(1.01, 10) = 1.1046221254112
      (dbx) print pow(1.01, 100.0)
      pow(1.01, 100) = 2.7048138294215
      (dbx) print pow(1.01, 1000.0)
      pow(1.01, 1000) = 20959.155637814
      (dbx) print pow(1.01, 10000.0)
      pow(1.01, 10000) = 1.635828711189e+43
      (dbx) print pow(1.01, 100000.0)
      pow(1.01, 100000) = Infinity
      (dbx) print pow(1.01, 1000000.0)
      pow(1.01, 1000000) = Infinity
      (dbx) print pow(1.01, 10000000.0)
      pow(1.01, 10000000) = Infinity
      (dbx) print pow(1.01, 100000000.0)
      pow(1.01, 100000000) = Infinity
      (dbx) print pow(1.01, 1000000000.0)
      pow(1.01, 1000000000) = 0.0
      (dbx) print pow(1.01, 10000000000.0)
      pow(1.01, 10000000000) = 0.0
      
      (dbx) print value
      value = 1.0111111111111
      (dbx) print val2
      val2 = 8796093022207.0
      
      (dbx) print pow(value, val2)
      pow(value, val2) = 0.0
      
      so it seems pow(1.01, y)
      returns Infinity for large y, but then starts to return 0.0 for even larger values of y.
      
      0b706e54
    • Bjorn Munch's avatar
      null upmerge · 3952f6bf
      Bjorn Munch authored
      3952f6bf
    • Bjorn Munch's avatar
      merge from 5.5-mtr · 825081b3
      Bjorn Munch authored
      825081b3
    • Bjorn Munch's avatar
      merge from 5.1-mtr · 147f897d
      Bjorn Munch authored
      147f897d
    • Bjorn Munch's avatar
    • Bjorn Munch's avatar
      null upmerge · 5ed1f306
      Bjorn Munch authored
      5ed1f306
    • Bjorn Munch's avatar
      merge from 5.5 main · abbc47f5
      Bjorn Munch authored
      abbc47f5
    • Bjorn Munch's avatar
      merge from 5.1 main · 031b52c4
      Bjorn Munch authored
      031b52c4
    • Marko Mäkelä's avatar
      Merge mysql-5.1 to mysql-5.5. · cbde5cb8
      Marko Mäkelä authored
      cbde5cb8
  5. 23 Sep, 2011 2 commits
  6. 22 Sep, 2011 1 commit
  7. 21 Sep, 2011 5 commits
    • Tor Didriksen's avatar
      Bug#12985030 SIMPLE QUERY WITH DECIMAL NUMBERS LEAKS MEMORY · f9b064a4
      Tor Didriksen authored
      Extra fix: 'if (p5 < p5_a + P5A_MAX)' is not portable.
      p5 starts out pointing to a static array, then may point
      to a buffer on the stack, then may point to malloc()ed memory.
      f9b064a4
    • Daniel Fischer's avatar
      post-merge fix · 8e56eb58
      Daniel Fischer authored
      8e56eb58
    • Daniel Fischer's avatar
      merge from 5.5.16 · 7450044e
      Daniel Fischer authored
      7450044e
    • unknown's avatar
      Bug 12963823 - Crash in Purge thread under unusual circumstances. · d27d267e
      unknown authored
      The problem occurred when indexes are added between the time that an
      UNDO record is created and the time that the purge thread comes around
      and deletes the old secondary index entries.  The purge thread would
      hit an assert when trying to build a secondary index entry for
      searching.  The problem was that the old value of those fields were not
      in the UNDO record since they were not part of an index when the UPDATE
      occured. 
      A test case was added to innodb-index.test.
      d27d267e
    • unknown's avatar
      Bug 12963823 - Crash in Purge thread under unusual circumstances. · 265737d1
      unknown authored
      The problem occurred when indexes are added between the time that an
      UNDO record is created and the time that the purge thread comes around
      and deletes the old secondary index entries.  The purge thread would
      hit an assert when trying to build a secondary index entry for
      searching.  The problem was that the old value of those fields were not
      in the UNDO record since they were not part of an index when the UPDATE
      occured. 
      A test case was added to innodb-index.test.
      265737d1
  8. 20 Sep, 2011 6 commits
  9. 19 Sep, 2011 4 commits
  10. 16 Sep, 2011 4 commits
    • Rafal Somla's avatar
      Update of auth_rpl test. · c388e9c4
      Rafal Somla authored
      For some reason the test authentication plugin accepted connection with arbitrary password. But the intention of the plugin is that password should equal to the authentication string and in the later versions of the server connection fails if password is wrong. So I have updated auth_rpl test to specify the correct password.
      c388e9c4
    • Sergey Vojtovich's avatar
      Merge. · cb9e23bb
      Sergey Vojtovich authored
      cb9e23bb
    • Sergey Vojtovich's avatar
      Merge. · a33b4214
      Sergey Vojtovich authored
      a33b4214
    • Sergey Vojtovich's avatar
      BUG#11761180 - 53646: MYISAMPACK CORRUPTS TABLES WITH · 3f9cbd77
      Sergey Vojtovich authored
                     FULLTEXT INDEXES
      
      myisamchk may create incorrect fulltext index for compressed
      tables. Incorrect data pointer size was used while creating
      fulltext index.
      
      mysql-test/r/myisampack.result:
        A test case for BUG#11761180.
      mysql-test/t/myisampack.test:
        A test case for BUG#11761180.
      storage/myisam/ft_boolean_search.c:
        rec_reflength on share may have adjustments required for
        compressed tables and must be used instead of rec_reflength
        on base info.
      storage/myisam/ft_nlq_search.c:
        rec_reflength on share may have adjustments required for
        compressed tables and must be used instead of rec_reflength
        on base info.
      storage/myisam/mi_check.c:
        rec_reflength on share may have adjustments required for
        compressed tables and must be used instead of rec_reflength
        on base info.
      storage/myisam/mi_write.c:
        rec_reflength on share may have adjustments required for
        compressed tables and must be used instead of rec_reflength
        on base info.
      3f9cbd77