1. 04 Sep, 2009 1 commit
    • 's avatar
      BUG#45581 Test rpl_row_sp006_InnoDB fails randomly: Unknown database 'mysqltest1' · 73a5527e
      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'.
      73a5527e
  2. 03 Sep, 2009 4 commits
    • Satya B's avatar
      merge mysql-5.0-bugteam to mysql-5.1-bugteam · 6f7c7850
      Satya B authored
      6f7c7850
    • Satya B's avatar
      Fix for Bug#33785 - myisamchk show warning message · 5a41fb5c
      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
      5a41fb5c
    • Satya B's avatar
      merge mysql-5.0-bugteam to mysql-5.1-bugteam · fc2243d6
      Satya B authored
      fc2243d6
    • Satya B's avatar
      Fix for BUG#46591 - .frm file isn't sync'd with sync_frm enabled for · 4a9e7e8e
      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.
      4a9e7e8e
  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 · 7aa88fcb
      Staale Smedseng authored
      7aa88fcb
    • Alexey Kopytov's avatar
      Automerge. · 6070491d
      Alexey Kopytov authored
      6070491d
    • Alexey Kopytov's avatar
      Bug #46607: Assertion failed: (cond_type == Item::FUNC_ITEM) · 62b95b90
      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(). 
      62b95b90
  7. 29 Aug, 2009 1 commit
    • 's avatar
      Bug #44331 Restore of database with events produces warning in replication · 90e25c6f
      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.
      90e25c6f
  8. 28 Aug, 2009 1 commit