1. 29 Oct, 2010 6 commits
    • Georgi Kodinov's avatar
      fix tree name · 9d4434e3
      Georgi Kodinov authored
      9d4434e3
    • Georgi Kodinov's avatar
      merge · 7de8306c
      Georgi Kodinov authored
      7de8306c
    • Sergey Glukhov's avatar
      5.1-security->5.5-security merge · 982b18f5
      Sergey Glukhov authored
      982b18f5
    • Sergey Glukhov's avatar
      Bug#57688 Assertion `!table || (!table->write_set || bitmap_is_set(table->write_set, field · 4a23ac20
      Sergey Glukhov authored
      Lines below which were added in the patch for Bug#56814 cause this crash:
      
      +      if (table->table)
      +        table->table->maybe_null= FALSE;
      
      Consider following test case:
      --
      CREATE TABLE t1(f1 INT NOT NULL);
      INSERT INTO t1 VALUES (16777214),(0);
      
      SELECT COUNT(*) FROM t1 LEFT JOIN t1 t2
      ON 1 WHERE t2.f1 > 1 GROUP BY t2.f1;
      
      DROP TABLE t1;
      --
      
      We set TABLE::maybe_null to FALSE for t2 table
      and in create_tmp_field() we create appropriate tmp table field
      using create_tmp_field_from_item() function instead of
      create_tmp_field_from_field. As a result we have
      LONGLONG field. As we have GROUP BY clause we calculate
      group buffer length, see calc_group_buffer().
      Item from group list which is used for calculation
      refer to the field from real tables and have LONG type.
      So group buffer length become insufficient for storing of
      LONGLONG value. It leads to overwriting of wrong memory
      area in do_field_int() function which is called from
      end_update().
      After some investigation I found out that
      create_tmp_field_from_item() is used only for OLAP
      grouping and can not be used for common grouping
      as it could be an incompatibility between tmp
      table fields and group buffer length.
      We can not remove create_tmp_field_from_item() call from
      create_tmp_field as OLAP needs it and we can not use this
      function for common grouping. So we should remove setting
      TABLE::maybe_null to FALSE from simplify_joins().
      In this case we'll get wrong behaviour of
      list_contains_unique_index() back. To fix it we
      could use Field::real_maybe_null() check instead of
      Field::maybe_null() and add addition check of
      TABLE_LIST::outer_join.
      
      
      mysql-test/r/group_by.result:
        test case
      mysql-test/r/join_outer.result:
        test case
      mysql-test/t/group_by.test:
        test case
      mysql-test/t/join_outer.test:
        test case
      sql/sql_select.cc:
        --remove wrong code
        --use Field::real_maybe_null() check instead of
          Field::maybe_null() and add addition check of
          TABLE_LIST::outer_join
      4a23ac20
    • Sergey Glukhov's avatar
      5.1-security->5.5-security · 7799c323
      Sergey Glukhov authored
      7799c323
    • Sergey Glukhov's avatar
      Bug#57194 group_concat cause crash and/or invalid memory reads with type errors · c04bf683
      Sergey Glukhov authored
      The problem is caused by bug49487 fix and became visible
      after after bug56679 fix.
      Items are cleaned up and set to unfixed state after filling derived table.
      So we can not rely on item::fixed state in Item_func_group_concat::print
      and we can not use 'args' array as items there may be cleaned up.
      The fix is always to use orig_args array of items as it
      always should contain the correct data.
      
      
      mysql-test/r/func_gconcat.result:
        test case
      mysql-test/t/func_gconcat.test:
        test case
      sql/item_sum.cc:
        The fix is always to use orig_args array of items.
      c04bf683
  2. 27 Oct, 2010 1 commit
  3. 29 Oct, 2010 4 commits
  4. 28 Oct, 2010 6 commits
    • Vasil Dimov's avatar
      Fix a compilation warning: · e3decfa0
      Vasil Dimov authored
      /export/home/pb2/build/sb_0-2459340-1288264809.63/mysql-5.5.8-ga/storage/innobase/os/os0sync.c: In function 'os_cond_wait_timed':
      /export/home/pb2/build/sb_0-2459340-1288264809.63/mysql-5.5.8-ga/storage/innobase/os/os0sync.c:184: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'time_t'
      gmake[2]: *** [storage/innobase/CMakeFiles/innobase.dir/os/os0sync.c.o] Error 1 
      e3decfa0
    • Mattias Jonsson's avatar
      post merge fix · 1a9083b9
      Mattias Jonsson authored
      1a9083b9
    • Calvin Sun's avatar
      8fc8e01f
    • Calvin Sun's avatar
      Bug#52062: Compiler warning in os0file.c on windows 64-bit · ec51b479
      Calvin Sun authored
      On Windows, the parameter for number of bytes passed into WriteFile()
      and ReadFile() is DWORD. Casting is needed to silence the warning on
      64-bit Windows.
      
      Also, adding several asserts to ensure the variable for number of bytes
      is no more than 32 bits, even on 64-bit Windows.
      
      rb://415
      Approved by: Inaam
      ec51b479
    • Calvin Sun's avatar
      Bug#52062: Compiler warning in os0file.c on windows 64-bit · 460ad14e
      Calvin Sun authored
      On Windows, the parameter for number of bytes passed into WriteFile()
      and ReadFile() is DWORD. Casting is needed to silence the warning on
      64-bit Windows.
      
      Also, adding several asserts to ensure the variable for number of bytes
      is no more than 32 bits, even on 64-bit Windows.
      
      This is for InnoDB Plugin.
      
      rb://415
      Approved by: Inaam
      460ad14e
    • Calvin Sun's avatar
      Bug#52062: Compiler warning in os0file.c on windows 64-bit · 16feea41
      Calvin Sun authored
      On Windows, the parameter for number of bytes passed into WriteFile()
      and ReadFile() is DWORD. Casting is needed to silence the warning on
      64-bit Windows.
      
      Also, adding several asserts to ensure the variable for number of bytes
      is no more than 32 bits, even on 64-bit Windows.
      
      This is for built-in InnoDB.
      
      rb://415
      Approved by: Inaam
      16feea41
  5. 27 Oct, 2010 12 commits
  6. 26 Oct, 2010 4 commits
    • Inaam Rana's avatar
      Bug #57611 ibdata file and continuous growing undo logs · 1c3dc21f
      Inaam Rana authored
        rb://498
        
        Fix handling of update_undo_logs at trx commit. Previously, when
        rseg->update_undo_list grows beyond 500 the update_undo_logs were
        marked with state TRX_UNDO_TO_FREE which should have been
        TRX_UNDO_TO_PURGE.
        In 5.5 we don't need the heuristic as we support multiple rollback
        segments.
        
        Approved by: Sunny Bains
      1c3dc21f
    • Inaam Rana's avatar
      29d62e4c
    • Inaam Rana's avatar
      Bug #57611 ibdata file and continuous growing undo logs · 26738c28
      Inaam Rana authored
      rb://498
      
      Fix handling of update_undo_logs at trx commit. Previously, when
      rseg->update_undo_list grows beyond 500 the update_undo_logs were
      marked with state TRX_UNDO_TO_FREE which should have been
      TRX_UNDO_TO_PURGE.
      
      Approved by: Sunny Bains
      26738c28
    • unknown's avatar
      Bug#57720 - Windows Vista and possibly Windows 7 can return ERROR_TIMEOUT... · 840c602e
      unknown authored
      Bug#57720 - Windows Vista and possibly Windows 7 can return ERROR_TIMEOUT instead of WAIT_TIMEOUT from calls to SleepConditionVariableCS() which is used in os0sync.c; os_cond_wait_timeout() where it is mapped to sleep_condition_variable().   
      
      Consider ERROR_TIMEOUT to be a timeout just like WAIT_TIMEOUT.  
      
      In addition, test for EINTR as a possible return value from pthread_cond_timeout() in the posix section of os_cond_wait_timeout(), even though it is not supposed to be returned, but just to be safe.
      840c602e
  7. 25 Oct, 2010 1 commit
    • Georgi Kodinov's avatar
      Bug #57689: mysql_change_user() breaks user connection on older clients · ef7982fd
      Georgi Kodinov authored
      COM_CHANGE_USER was always handled like an implicit request to change the
      client plugin, so that the client can re-use the same code path for both normal 
      login and COM_CHANGE_USER. However this doesn't really work well with old 
      clients because they don't understand the request to change a client plugin.
      
      Fixed by implementing a special state in the code (and old client issuing 
      COM_CHANGE_USER). In this state the server parses the COM_CHANGE_USER 
      package and pushes back the password hash, the user name and the database 
      to the input stream in the same order that the native password server side plugin 
      expects. As a result it replies with an OK/FAIL just like the old server does thus
      making the new server compatible with older clients.
      
      No test case added, since it would requre an old client binary. Tested using 
      accounts with and without passwords. Tested with a correct and incorrect 
      password.
      ef7982fd
  8. 27 Oct, 2010 4 commits
  9. 26 Oct, 2010 2 commits