1. 30 Oct, 2012 4 commits
    • Anirudh Mangipudi's avatar
      BUG#11754894: MYISAMCHK ERROR HAS INCORRECT REFERENCE · a18a3474
      Anirudh Mangipudi authored
                    TO 'MYISAM_SORT_BUFFER_SIZE'
      Merging from 5.1 to 5.5
      a18a3474
    • Anirudh Mangipudi's avatar
      BUG#11754894: MYISAMCHK ERROR HAS INCORRECT REFERENCE · 84d87d93
      Anirudh Mangipudi authored
                    TO 'MYISAM_SORT_BUFFER_SIZE'
      Problem: 'myisam_sort_buffer_size' is a parameter used by 
      mysqld program only whereas 'sort_buffer_size' is used by
      mysqld and myisamchk programs. But the error message printed
      when myisamchk program is run with insufficient buffer size 
      is myisam_sort_buffer_size is too small which may mislead to the
      server parameter myisam_sort_buffer_size.
      SOLUTION: A parameter 'myisam_sort_buffer_size' is added as an
      alias for 'sort_buffer_size' and the 'sort_buffer_size' parameter
      is marked as deprecated. So myisamchk also has both the parameters
      with the same role.
      84d87d93
    • Shivji Kumar Jha's avatar
    • Shivji Kumar Jha's avatar
      BUG#14659685 - main.mysqlbinlog_row_myisam and · 7c7de142
      Shivji Kumar Jha authored
                     main.mysqlbinlog_row_innodb are skipped by mtr
      
      === Problem ===
      
      The following tests are wrongly placed in main suite and as a
      result these are not run with proper binlog format combinations.
      Some are always skipped by mtr.
      1) mysqlbinlog_row_myisam
      2) mysqlbinlog_row_innodb
      3) mysqlbinlog_row.test
      4) mysqlbinlog_row_trans.test
      5) mysqlbinlog-cp932
      6) mysqlbinlog2
      7) mysqlbinlog_base64
      
      === Background ===
      
      mtr runs the tests placed in main suite with binlog format=stmt.
      Those that need to be tested against binlog format=row or mixed
      or more than one binlog format and require only one mysql server
      are placed in binlog suite. mtr runs tests in binlog suite with
      all three binlog formats(stmt,row and mixed).
      
      === Fix ===
      
      
      1) Moved the test listed in problem section above to binlog suite.
      2) Added prefix "binlog_" to the name of each test case moved.
         Renamed the coresponding result files and option files accordingly. 
      
      
      mysql-test/extra/binlog_tests/mysqlbinlog_row_engine.inc:
        include file for mysqlbinlog_row_myisam.test and 
        mysqlbinlog_row_myisam.test which are being moved to
        binlog suite.
      mysql-test/suite/binlog/r/binlog_mysqlbinlog-cp932.result:
        result file for mysqlbinlog-cp932.test which is being moved to
        binlog suite.
      mysql-test/suite/binlog/r/binlog_mysqlbinlog2.result:
        result file for mysqlbinlog2.test which is being moved to
        binlog suite.
      mysql-test/suite/binlog/r/binlog_mysqlbinlog_base64.result:
        result file for mysqlbinlog_base64.test which is being moved to
        binlog suite.
      mysql-test/suite/binlog/r/binlog_mysqlbinlog_row.result:
        result file for mysqlbinlog_row.test which is being moved to
        binlog suite.
      mysql-test/suite/binlog/r/binlog_mysqlbinlog_row_innodb.result:
        result file for mysqlbinlog_row_innodb.test which is being moved to
        binlog suite.
      mysql-test/suite/binlog/r/binlog_mysqlbinlog_row_myisam.result:
        result file for mysqlbinlog_row_myisam.test which is being moved to
        binlog suite.
      mysql-test/suite/binlog/r/binlog_mysqlbinlog_row_trans.result:
        result file for mysqlbinlog_row_trans.test which is being moved to
        binlog suite.
      mysql-test/suite/binlog/t/binlog_mysqlbinlog-cp932-master.opt:
        option file for mysqlbinlog-cp932.test which is being moved to
        binlog suite.
      mysql-test/suite/binlog/t/binlog_mysqlbinlog-cp932.test:
        the test requires binlog format=stmt or mixed. Since, it was placed in
        main suite earlier, it was only run with binlog format=stmt, and hence
        this test was never run with binlog format=mixed.
      mysql-test/suite/binlog/t/binlog_mysqlbinlog2.test:
        the test requires binlog format=stmt or mixed. Since, it was placed in
        main suite earlier, it was only run with binlog format=stmt, and hence
        this test was never run with binlog format=mixed.
      mysql-test/suite/binlog/t/binlog_mysqlbinlog_base64.test:
        the test requires binlog format=row. Since, it was placed in main
        suite earlier, it was only run with binlog format=stmt, and hence
        this test was always skipped by mtr.
      mysql-test/suite/binlog/t/binlog_mysqlbinlog_row.test:
        the test requires binlog format=row. Since, it was placed in main
        suite earlier, it was only run with binlog format=stmt, and hence
        this test was always skipped by mtr.
      mysql-test/suite/binlog/t/binlog_mysqlbinlog_row_innodb.test:
        the test requires binlog format=row. Since, it was placed in main
        suite earlier, it was only run with binlog format=stmt, and hence
        this test was always skipped by mtr.
      mysql-test/suite/binlog/t/binlog_mysqlbinlog_row_myisam.test:
        the test requires binlog format=row. Since, it was placed in main
        suite earlier, it was only run with binlog format=stmt, and hence
        this test was always skipped by mtr.
      mysql-test/suite/binlog/t/binlog_mysqlbinlog_row_trans.test:
        the test requires binlog format=row. Since, it was placed in main
        suite earlier, it was only run with binlog format=stmt, and hence
        this test was always skipped by mtr.
      7c7de142
  2. 29 Oct, 2012 6 commits
  3. 24 Oct, 2012 1 commit
  4. 23 Oct, 2012 2 commits
  5. 22 Oct, 2012 2 commits
    • Marko Mäkelä's avatar
      Merge mysql-5.1 to mysql-5.5. · e5b11572
      Marko Mäkelä authored
      e5b11572
    • Marko Mäkelä's avatar
      Backport from 5.6: Bug#14769820 ASSERT FLEN == LEN · d13554b1
      Marko Mäkelä authored
      IN ALTER TABLE ... ADD UNIQUE KEY
      
      A bogus debug assertion failure occurred when reporting a duplicate
      key on a column prefix of a CHAR column.
      
      This is a regression from Bug#14729221 IN-PLACE ALTER TABLE REPORTS ''
      INSTEAD OF REAL DUPLICATE VALUE FOR PREFIX KEYS. The assertion is only
      present when UNIV_DEBUG is defined (which it is in debug builds
      starting from MySQL 5.5). It is a case of overasserting.
      
      Fix approved by Inaam Rana on IM.
      d13554b1
  6. 21 Oct, 2012 5 commits
  7. 19 Oct, 2012 4 commits
  8. 18 Oct, 2012 4 commits
    • Neeraj Bisht's avatar
      Bug#13726751 - 8 BYTE MEMORY LEAK IN DO_SAVE_BLOB · 44beb951
      Neeraj Bisht authored
      Problem:-
      When we execute a query which has subquery with GROUP BY, ORDER BY and have a
      BLOB column,results a memory leak.
      
      Analysis:-
      In case of subquery, which have GROUP BY on BLOB and a ORDER BY on other field
      and BLOB is not a key. We allocate a tmp buffer to copy_field to take care of
      BLOB value.This copy_field value can have copies of its in two join(objects),
      so while freeing this copy_field we have to take care that it is
      not deleted twice.
      The double deletion of tmp_table_param.copy_field is handled by two patches.
      
      One by Kostja :
      revid:sp1r-konstantin@mysql.com-20050627101056-55153
      Fix the broken test suite in -debug build.
      
      and other by Oleksandr
      revid:sp1r-bell@sanja.is.com.ua-20060118114857-19905
      Excluded posibility of tmp_table_param.copy_field double deletion (BUG#14851).
      
      both of this patches are commited in different branch and while
      merging they both get placed,but there is no need for Kostja patch as Oleksandr
      patch handle this.
      
      
      sql/sql_select.cc:
        Bug13726751, tmp_join clean up is not necessary as later in the code we are taking care of cleaning up of tmp_join copy_field.
      44beb951
    • Neeraj Bisht's avatar
      Bug#13726751 - 8 BYTE MEMORY LEAK IN DO_SAVE_BLOB · eef1a195
      Neeraj Bisht authored
      Problem:-
      When we execute a query which has subquery with GROUP BY, ORDER BY and have a
      BLOB column,results a memory leak.
      
      Analysis:-
      In case of subquery, which have GROUP BY on BLOB and a ORDER BY on other field
      and BLOB is not a key. We allocate a tmp buffer to copy_field to take care of
      BLOB value.This copy_field value can have copies of its in two join(objects),
      so while freeing this copy_field we have to take care that it is
      not deleted twice.
      The double deletion of tmp_table_param.copy_field is handled by two patches.
      
      One by Kostja :
      revid:sp1r-konstantin@mysql.com-20050627101056-55153
      Fix the broken test suite in -debug build.
      
      and other by Oleksandr
      revid:sp1r-bell@sanja.is.com.ua-20060118114857-19905
      Excluded posibility of tmp_table_param.copy_field double deletion (BUG#14851).
      
      both of this patches are commited in different branch and while
      merging they both get placed,but there is no need for Kostja patch as Oleksandr
      patch handle this.
      
      
      sql/sql_select.cc:
        Bug13726751, tmp_join clean up is not necessary as later in the code we are taking care of cleaning up of tmp_join copy_field.
      eef1a195
    • Marko Mäkelä's avatar
      Merge mysql-5.1 to mysql-5.5. · f9389d58
      Marko Mäkelä authored
      f9389d58
    • Marko Mäkelä's avatar
      Bug#14758405: ALTER TABLE: ADDING SERIAL NULL DATATYPE: ASSERTION: · 52ea1522
      Marko Mäkelä authored
      LEN <= SIZEOF(ULONGLONG)
      
      This bug was caught in the WL#6255 ALTER TABLE...ADD COLUMN in MySQL
      5.6, but there is a bug in all InnoDB versions that support
      auto-increment columns.
      
      row_search_autoinc_read_column(): When reading the maximum value of
      the auto-increment column, and the column only contains NULL values,
      return 0. This corresponds to the case when the table is empty in
      row_search_max_autoinc().
      
      rb:1415 approved by Sunny Bains
      52ea1522
  9. 17 Oct, 2012 11 commits
  10. 16 Oct, 2012 1 commit
    • Neeraj Bisht's avatar
      Bug#11745891 - LAST_INSERT(ID) DOES NOT SUPPORT BIGINT UNSIGNED · 510d048b
      Neeraj Bisht authored
      Problem:-
      using last_insert_id() on an auto_incremented bigint unsigned does
      not work for values which are greater than max-bigint-signed.
      
      Analysis:-
      last_insert_id() returns the first auto_incremented value for a column
      and an auto_incremented value can have only positive values.
      
      In our code, when we are initializing a last_insert_id object, we are
      taking it as a signed BIGINT, So when the auto_incremented value reaches
      greater than max signed bigint, last_insert_id gives negative result.
      
      Solution:
      When we are fetching the value from last_insert_id, We are setting the 
      unsigned_flag, so that it take only unsigned BIGINT value.
      
      sql/item_func.cc:
        here unsigned value is converted to signed value.
      sql/item_func.h:
        last_insert_id() gives an auto_incremented value which can be
        positive only,so defined it as a unsigned longlong sets the
        unsigned_flag to 1.
      510d048b