1. 11 Nov, 2010 1 commit
    • Alexander Barkov's avatar
      Bug#57257 Replace(ExtractValue(...)) causes MySQL crash · a5d6c009
      Alexander Barkov authored
      Bug#57820 extractvalue crashes
      
      Problem: ExtractValue and Replace crashed in some cases
      due to invalid handling of empty and NULL arguments.
      
      Per file comments:
      
        @mysql-test/r/ctype_ujis.result
        @mysql-test/r/xml.result
        @mysql-test/t/ctype_ujis.test
        @mysql-test/t/xml.test
        Adding tests
      
        @sql/item_strfunc.cc
        Make sure Item_func_replace::val_str safely handles empty strings.
      
        @sql/item_xmlfunc.cc
        set null_value if nodeset_func returned NULL,
        which is possible when the second argument is an
        unset user variable.
      a5d6c009
  2. 08 Nov, 2010 3 commits
  3. 03 Nov, 2010 2 commits
  4. 01 Nov, 2010 2 commits
  5. 29 Oct, 2010 7 commits
    • Georgi Kodinov's avatar
      merge · 263a7054
      Georgi Kodinov authored
      263a7054
    • Georgi Kodinov's avatar
      merge to 5.1-security · bb592e9c
      Georgi Kodinov authored
      bb592e9c
    • Georgi Kodinov's avatar
      merge to 5.1-security · e223f2bc
      Georgi Kodinov authored
      e223f2bc
    • Georgi Kodinov's avatar
      merge to 5.0-security · 92223604
      Georgi Kodinov authored
      92223604
    • Sergey Glukhov's avatar
      Bug#57688 Assertion `!table || (!table->write_set || bitmap_is_set(table->write_set, field · 5b318c5a
      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
      5b318c5a
    • Vasil Dimov's avatar
      Merge mysql-5.1-innodb -> mysql-5.1-bugteam · 17d12386
      Vasil Dimov authored
      17d12386
    • Sergey Glukhov's avatar
      Bug#57194 group_concat cause crash and/or invalid memory reads with type errors · 54e7559f
      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.
      54e7559f
  6. 28 Oct, 2010 2 commits
    • Calvin Sun's avatar
      Bug#52062: Compiler warning in os0file.c on windows 64-bit · da1e3612
      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
      da1e3612
    • Calvin Sun's avatar
      Bug#52062: Compiler warning in os0file.c on windows 64-bit · e0e2446d
      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
      e0e2446d
  7. 27 Oct, 2010 3 commits
  8. 26 Oct, 2010 1 commit
  9. 25 Oct, 2010 3 commits
  10. 23 Oct, 2010 1 commit
    • unknown's avatar
      Bug#27606 GRANT statement should be replicated with DEFINER information · 650f0081
      unknown authored
      "Grantor" columns' data is lost when replicating mysql.tables_priv.
      Slave SQL thread used its default user ''@'' as the grantor of GRANT|REVOKE
      statements executing on it.
      
      In this patch, current user is put in query log event for all GRANT and REVOKE
      statement, SQL thread uses the user in query log event as grantor.
      
      
      mysql-test/suite/rpl/r/rpl_do_grant.result:
        Add test for this bug.
      mysql-test/suite/rpl/t/rpl_do_grant.test:
        Add test for this bug.
      sql/log_event.cc:
        Refactoring THD::current_user_used and related functions.
        current_user_used is used to judge if current user should be
        binlogged in query log event. So it is better to call it m_binlog_invoker.
        The related functions are renamed too.
      sql/sql_class.cc:
        Refactoring THD::current_user_used and related functions.
        current_user_used is used to judge if current user should be
        binlogged in query log event. So it is better to call it m_binlog_invoker.
        The related functions are renamed too.
      sql/sql_class.h:
        Refactoring THD::current_user_used and related functions.
        current_user_used is used to judge if current user should be
        binlogged in query log event. So it is better to call it m_binlog_invoker.
        The related functions are renamed too.
      sql/sql_parse.cc:
        Call binlog_invoker() for GRANT and REVOKE statements.
      650f0081
  11. 21 Oct, 2010 4 commits
    • Bjorn Munch's avatar
      Follow-up to Bug #55582 which allows checking strings in if · 09694be3
      Bjorn Munch authored
        Simplified cases where a select was used to compare variable against ''
      09694be3
    • unknown's avatar
      Bug#55478 Row events wrongly apply on the temporary table of the same name · ff9140b5
      unknown authored
      Rows events were applied wrongly on the temporary table with the same name.
      But rows events are generated only for base tables. As temporary
      table's data never be binlogged on row mode. Normally, base table of the
      same name cannot be updated if a temporary table has the same name.
      But there are two cases which can generate rows events on 
      the base table of same name.
            
      Case1: 'CREATE TABLE ... SELECT' statement.
      In mixed format, it will generate rows events if it is unsafe.
            
      Case2: Drop a transactional temporary table in a transaction
             (happens only on 5.5+).
      BEGIN;
      DROP TEMPORARY TABLE t1;       # t1 is a InnoDB table
      INSERT INTO t1 VALUES(rand()); # t1 is a MyISAM table
      COMMIT;
      'DROP TEMPORARY TABLE' will be put in the transaction cache and
      binlogged after the rows events generated by the 'INSERT' statement.
            
      After this patch, slave opens only base table when applying a rows event.
      ff9140b5
    • Jimmy Yang's avatar
      Fix Bug #57616 Sig 11 in dict_load_table() when failed to load · cd3f17bd
      Jimmy Yang authored
      index or foreign key
      
      Approved by Sunny Bains
      cd3f17bd
    • Jimmy Yang's avatar
      Fix bug #57616 Sig 11 in dict_load_table() when failed to load index · 1918a8cf
      Jimmy Yang authored
      or foreign key
      
      Fix approved by Sunny Bains
      1918a8cf
  12. 20 Oct, 2010 6 commits
  13. 19 Oct, 2010 5 commits