An error occurred fetching the project authors.
  1. 29 Sep, 2011 4 commits
    • Rafal Somla's avatar
      Bug#12982926 CLIENT CAN OVERRIDE ZERO-LENGTH-ALLOCATE BUFFER · 84f077bf
      Rafal Somla authored
      Changes in client plugin needed for testing the issue (test instrumentation).
      84f077bf
    • Marko Mäkelä's avatar
      Update the German error message translations (by Stefan Hinz) · f30d2bd7
      Marko Mäkelä authored
      and fix some Swedish too.
      f30d2bd7
    • Andrei Elkin's avatar
      Bug#11747416 : 32228 A disk full makes binary log corrupt · 4a6d85b5
      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.
      4a6d85b5
    • Rohit Kalhans's avatar
      BUG#11758262 - 50439: MARK INSERT...SEL...ON DUP KEY UPD,REPLACE...SEL,CREATE...[IGN|REPL] SEL · 8c4a42e7
      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.
      8c4a42e7
  2. 28 Sep, 2011 2 commits
  3. 27 Sep, 2011 3 commits
  4. 26 Sep, 2011 10 commits
    • Tor Didriksen's avatar
      local merge · 136802d7
      Tor Didriksen authored
      136802d7
    • Tor Didriksen's avatar
      Bug#12985030 SIMPLE QUERY WITH DECIMAL NUMBERS LEAKS MEMORY · 3a2f4fca
      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.
      
      3a2f4fca
    • Bjorn Munch's avatar
      null upmerge · f24d9a6d
      Bjorn Munch authored
      f24d9a6d
    • Bjorn Munch's avatar
      merge from 5.5-mtr · 5760b08c
      Bjorn Munch authored
      5760b08c
    • Bjorn Munch's avatar
      merge from 5.1-mtr · 5cdba185
      Bjorn Munch authored
      5cdba185
    • Bjorn Munch's avatar
    • Bjorn Munch's avatar
      null upmerge · 1873ea3f
      Bjorn Munch authored
      1873ea3f
    • Bjorn Munch's avatar
      merge from 5.5 main · 165b3242
      Bjorn Munch authored
      165b3242
    • Bjorn Munch's avatar
      merge from 5.1 main · b8907ffa
      Bjorn Munch authored
      b8907ffa
    • Marko Mäkelä's avatar
      Merge mysql-5.1 to mysql-5.5. · 7a56653f
      Marko Mäkelä authored
      7a56653f
  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 · d9f48df3
      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.
      d9f48df3
    • Daniel Fischer's avatar
      post-merge fix · b879b2a4
      Daniel Fischer authored
      b879b2a4
    • Daniel Fischer's avatar
      merge from 5.5.16 · 65ef9e4c
      Daniel Fischer authored
      65ef9e4c
    • unknown's avatar
      Bug 12963823 - Crash in Purge thread under unusual circumstances. · a5f8796e
      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.
      a5f8796e
    • unknown's avatar
      Bug 12963823 - Crash in Purge thread under unusual circumstances. · 0b8242cd
      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.
      0b8242cd
  8. 20 Sep, 2011 6 commits
  9. 19 Sep, 2011 4 commits
  10. 16 Sep, 2011 3 commits
    • Rafal Somla's avatar
      Update of auth_rpl test. · d3c98f45
      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.
      d3c98f45
    • Sergey Vojtovich's avatar
      Merge. · d4496524
      Sergey Vojtovich authored
      d4496524
    • Sergey Vojtovich's avatar
      Merge. · f3c21f58
      Sergey Vojtovich authored
      f3c21f58