1. 04 Sep, 2009 2 commits
    • V Narayanan's avatar
      Bug#45823 Assertion failure in file row/row0mysql.c line 1386 · 9776b6f9
      V Narayanan authored
      Inserting a negative value in the autoincrement column of a
      partitioned innodb table was causing the value of the auto
      increment counter to wrap around into a very large positive
      value. The consequences are the same as if a very large positive
      value was inserted into a column, e.g. reduced autoincrement
      range, failure to read autoincrement counter.
      
      The current patch ensures that before calculating the next
      auto increment value, the current value is within the positive
      maximum allowed limit.
      
      mysql-test/suite/parts/inc/partition_auto_increment.inc:
        Bug#45823 Assertion failure in file row/row0mysql.c line 1386
        
        Adds tests for performing insert,update and delete on a partition
        table with negative auto_increment values.
      mysql-test/suite/parts/r/partition_auto_increment_innodb.result:
        Bug#45823 Assertion failure in file row/row0mysql.c line 1386
        
        Result file for the innodb engine.
      mysql-test/suite/parts/r/partition_auto_increment_memory.result:
        Bug#45823 Assertion failure in file row/row0mysql.c line 1386
        
        Result file for the memory engine.
      mysql-test/suite/parts/r/partition_auto_increment_myisam.result:
        Bug#45823 Assertion failure in file row/row0mysql.c line 1386
        
        Result file for the myisam engine.
      mysql-test/suite/parts/r/partition_auto_increment_ndb.result:
        Bug#45823 Assertion failure in file row/row0mysql.c line 1386
        
        Result file for the ndb engine.
      mysql-test/suite/parts/t/partition_auto_increment_archive.test:
        Bug#45823 Assertion failure in file row/row0mysql.c line 1386
        
        Adds a variable that allows the Archive engine to skip tests
        that involve insertion of negative auto increment values.
      mysql-test/suite/parts/t/partition_auto_increment_blackhole.test:
        Bug#45823 Assertion failure in file row/row0mysql.c line 1386
        
        Adds a variable that allows the Blackhole engine to skip tests
        that involve insertion of negative auto increment values.
      sql/ha_partition.cc:
        Bug#45823 Assertion failure in file row/row0mysql.c line 1386
        
        Ensures that the current value is lesser than the upper limit
        for the type of the field before setting the next auto increment
        value to be calculated.
      sql/ha_partition.h:
        Bug#45823 Assertion failure in file row/row0mysql.c line 1386
        
        Modifies the set_auto_increment_if_higher function, to take
        into account negative auto increment values when doing a
        comparison.
      9776b6f9
    • unknown's avatar
      BUG#45581 Test rpl_row_sp006_InnoDB fails randomly: Unknown database 'mysqltest1' · 1eb40ce3
      unknown authored
            
      Essentially, Bug#45574 results in this bug. The 'CREATE DATABASE IF NOT EXISTS' statement was not 
      binlogged, when the database has existed.
      Sometimes, the master and slaves become inconsistent. The "CREATE DATABASE
      IF NOT EXISTS mysqltest1" statement is not binlogged
      if the db 'mysqltest1' existed before the test case is executed. 
      So the db 'mysqltest1' can't be created on slave.
           
      Patch of Bug#45574 has resolved this problem. 
      But I think it is better to replace 'mysqltest1' by default db 'test'.
      1eb40ce3
  2. 03 Sep, 2009 4 commits
    • Satya B's avatar
      merge mysql-5.0-bugteam to mysql-5.1-bugteam · 421531df
      Satya B authored
      421531df
    • Satya B's avatar
      Fix for Bug#33785 - myisamchk show warning message · fe79cb53
      Satya B authored
      myisamchk tool generates warnings when run on an myisam files (.MYI or .MYD)
      This is because of the conversion of max_value for certain options in myisamchk 
      from singed long to unsigned long
      
      The max value for the options key_buffer_size, read_buffer_size, write_buffer
      _size and sort_buffer_size is given as (long) ~0L which becomes -1  when casted
      from signed long to longlong and then casted to ulonglong. When (ulonglong) -1 
      is compared with maximal value for GET_ULONG data type, we adjust it to 
      (ulonglong) ULONG_MAX and throw the warning.
      
      Fixed by using the right max size.
      
      Max values for the variables (from mysqld.cc)
      ----------------------------
      1. key_buffer_size
         5.0: ULONG_MAX
         5.1: SIZE_T_MAX
         6.0: SIZE_T_MAX
      
      2. read_buffer_size and write_buffer_size
         5.0: INT_MAX32
         5.1: INT_MAX32
         6.0: INT_MAX32
      
      3. sort_buffer_size (aka myisam_sort_buffer_size)
         5.0: UINT_MAX32
         5.1: ULONG_MAX
         6.0: ULONG_MAX
      
      Note: testcase not attached
      
      myisam/myisamchk.c:
        Bug#33785 - myisamchk show warning message
            
        Fixed the Max value for key_buffer_size, read_buffer_size, write_buffer_size and
        sort_buffer_size options
      fe79cb53
    • Satya B's avatar
      merge mysql-5.0-bugteam to mysql-5.1-bugteam · 33f9066e
      Satya B authored
      33f9066e
    • Satya B's avatar
      Fix for BUG#46591 - .frm file isn't sync'd with sync_frm enabled for · 2fc9c5d1
      Satya B authored
                          CREATE TABLE...LIKE...
            
      The mysql server option 'sync_frm' is ignored when table is created with 
      syntax CREATE TABLE .. LIKE.. 
            
      Fixed by adding the MY_SYNC flag and calling my_sync() from my_copy() when
      the flag is set.
      
      In mysql_create_table(), when the 'sync_frm' is set, MY_SYNC flag is passed 
      to my_copy(). 
            
      Note: TestCase is not attached and can be tested manually using debugger.
      
      client/Makefile.am:
        BUG#46591 - .frm file isn't sync'd with sync_frm enabled for 
                    CREATE TABLE...LIKE...
            
        add my_sync to sources as it is used in my_copy() method
      include/my_sys.h:
        BUG#46591 - .frm file isn't sync'd with sync_frm enabled for 
                    CREATE TABLE...LIKE...
            
        MY_SYNC flag is added to call my_sync() method
      mysys/my_copy.c:
        BUG#46591 - .frm file isn't sync'd with sync_frm enabled for 
                    CREATE TABLE...LIKE...
            
        my_sync() is method is called when MY_SYNC is set in my_copy()
      sql/sql_table.cc:
        BUG#46591 - .frm file isn't sync'd with sync_frm enabled for 
                    CREATE TABLE...LIKE...
            
        Fixed mysql_create_like_table() to call my_sync() when opt_sync_frm variable
        is set
      2fc9c5d1
  3. 02 Sep, 2009 14 commits
  4. 01 Sep, 2009 5 commits
  5. 31 Aug, 2009 11 commits
  6. 30 Aug, 2009 3 commits
    • Staale Smedseng's avatar
      Merge from 5.1-bugteam · 4d7202a0
      Staale Smedseng authored
      4d7202a0
    • Alexey Kopytov's avatar
      Automerge. · 54e45160
      Alexey Kopytov authored
      54e45160
    • Alexey Kopytov's avatar
      Bug #46607: Assertion failed: (cond_type == Item::FUNC_ITEM) · 6ce48392
      Alexey Kopytov authored
                  results in server crash 
       
      check_group_min_max_predicates() assumed the input condition 
      item to be one of COND_ITEM, SUBSELECT_ITEM, or FUNC_ITEM. 
      Since a condition of the form "field" is also a valid condition 
      equivalent to "field <> 0", using such a condition in a query 
      where the loose index scan was chosen resulted in a debug 
      assertion failure. 
       
      Fixed by handling conditions of the FIELD_ITEM type in 
      check_group_min_max_predicates(). 
      
      mysql-test/r/group_min_max.result:
        Added a test case for bug #46607.
      mysql-test/t/group_min_max.test:
        Added a test case for bug #46607.
      sql/opt_range.cc:
        Handle conditions of the FUNC_ITEM type in 
        check_group_mix_max_predicates().
      6ce48392
  7. 29 Aug, 2009 1 commit
    • unknown's avatar
      Bug #44331 Restore of database with events produces warning in replication · f32c08bd
      unknown authored
      If an EVENT is created without the DEFINER clause set explicitly or with it set  
      to CURRENT_USER, the master and slaves become inconsistent. This issue stems from 
      the fact that in both cases, the DEFINER is set to the CURRENT_USER of the current 
      thread. On the master, the CURRENT_USER is the mysqld's user, while on the slave,  
      the CURRENT_USER is empty for the SQL Thread which is responsible for executing 
      the statement.
      
      To fix the problem, we do what follows. If the definer is not set explicitly,  
      a DEFINER clause is added when writing the query into binlog; if 'CURRENT_USER' is 
      used as the DEFINER, it is replaced with the value of the current user before 
      writing to binlog.
      
      mysql-test/suite/rpl/r/rpl_create_if_not_exists.result:
        Updated the result file after fixing bug#44331
      mysql-test/suite/rpl/r/rpl_drop_if_exists.result:
        Updated the result file after fixing bug#44331
      mysql-test/suite/rpl/r/rpl_events.result:
        Test result of Bug#44331
      mysql-test/suite/rpl/r/rpl_innodb_mixed_dml.result:
        Updated the result file after fixing bug#44331
      mysql-test/suite/rpl/t/rpl_events.test:
        Added test to verify if the definer is consistent between master and slave
        when the event is created without the DEFINER clause set explicitly or the
        DEFINER is set to CURRENT_USER
      sql/events.cc:
        The "create_query_string" function is added to create a new query string 
        for removing executable comments.
      sql/sql_yacc.yy:
        The remember_name token was added for recording the offset of EVENT_SYM.
      f32c08bd