An error occurred fetching the project authors.
  1. 29 Mar, 2014 1 commit
  2. 26 Mar, 2014 1 commit
  3. 14 Mar, 2014 1 commit
    • unknown's avatar
      MDEV-5446: Assertion `!table || (!table->read_set ||... · 5c8ed7dd
      unknown authored
      MDEV-5446: Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' fails on EXPLAIN EXTENDED with VALUES function
      
      field_index should be set correctly for null field created by Item_insert_value::fix_fields().
      5c8ed7dd
  4. 07 Mar, 2014 1 commit
  5. 06 Mar, 2014 1 commit
  6. 26 Feb, 2014 1 commit
  7. 19 Feb, 2014 1 commit
    • Sergey Vojtovich's avatar
      MDEV-5314 - Compiling fails on OSX using clang · d12c7adf
      Sergey Vojtovich authored
      This is port of fix for MySQL BUG#17647863.
      
      revno: 5572
      revision-id: jon.hauglid@oracle.com-20131030232243-b0pw98oy72uka2sj
      committer: Jon Olav Hauglid <jon.hauglid@oracle.com>
      timestamp: Thu 2013-10-31 00:22:43 +0100
      message:
        Bug#17647863: MYSQL DOES NOT COMPILE ON OSX 10.9 GM
      
        Rename test() macro to MY_TEST() to avoid conflict with libc++.
      d12c7adf
  8. 12 Feb, 2014 1 commit
  9. 11 Feb, 2014 1 commit
  10. 24 Jan, 2014 1 commit
    • Michael Widenius's avatar
      Fix for MDEV-5531: double call procedure in one session - hard shutdown the server · d15b3386
      Michael Widenius authored
      Main fix was to not cache derivied tables as they may be temporary tables that are deleted before the next query.
      This was a bit tricky as Item_field::fix_fields depended on cached_tables to be set to resolve some columns.
      
      
      
      mysql-test/r/sp-bugs.result:
        Added test case
      mysql-test/t/sp-bugs.test:
        Added test case
      sql/item.cc:
        Fixed fix_outer_field to handle case where found field did not have in cached_table
        Idea is that if cached_table is not avaliable, use from_field->table->pos_in_table_list instead
      sql/records.cc:
        Also accept INTERNAL_TMP_TABLE for memmap
      sql/sql_base.cc:
        More DBUG_PRINT
        Fixed that setup_natural_join_row_types() is not run twice.
        Original code modified context->first_name_resolution_table also for second executions.
        This was wrong as this could give wrong results if some joins had been optimized away between calls.
      sql/sql_derived.cc:
        Mark derived tables as internal temporary tables (INTERNAL_TMP_TABLE), not as NON_TRANSACTIONAL_TMP_TABLE.
        This is more correct as the tables are not visible by the end user.
      sql/sql_insert.cc:
        Reset pos_in_table_list before calling fix_fields.
        One of the consequences of the change of not caching all generated tables in Item_ident is that
        pos_in_table_list needs to be correct in calls to fix_fields.
      sql/sql_lex.cc:
        More DBUG_PRINT
      sql/sql_parse.cc:
        Don't cache derivied tables as they may be temporary tables that are deleted before the next query
      sql/sql_select.cc:
        Reset table_vector. This was required as some code checked the vector to see if temporary tables had already been created.
      sql/table.cc:
        Mark tables with field translations as cacheable (as these will not disapper between stmt executions.
      d15b3386
  11. 28 Nov, 2013 1 commit
    • Sergei Golubchik's avatar
      MDEV-4243 [PATCH] Warnings/errors while compiling with clang · ab360498
      Sergei Golubchik authored
      fix the code to compile with clang. fix warnings too.
      
      include/probes_mysql_nodtrace.h:
        clang++ doesn't like numeric _constants_ being used in ||
        (it suspects that the intention was | ). Boolean constants are ok.
      sql/hostname.cc:
        only used in DBUG_ASSERT
      sql/item.cc:
        str_to_time and str_to_datetime return bool, not MYSQL_TIMESTAMP_xxx
      sql/item_func.cc:
        str_to_datetime_with_warn() returns bool, not MYSQL_TIMESTAMP_xxx
      storage/cassandra/CMakeLists.txt:
        CMAKE_CXX_FLAGS can be empty
      storage/connect/odbconn.cpp:
        HWND is void*
      storage/connect/user_connect.h:
        deprecated on FreeBSD and unused anyway
      storage/connect/value.cpp:
        bad characters inside. unused.
      storage/spider/spd_trx.cc:
        clang++ warns that memset will also overwrite vtbl. it might be as well a good idea,
        as it asserts that the object will only be used as a storage.
        silence the warning.
      ab360498
  12. 21 Nov, 2013 1 commit
  13. 08 Nov, 2013 1 commit
  14. 04 Oct, 2013 1 commit
    • Igor Babaev's avatar
      Fixed bug mdev-5078. · ec226e55
      Igor Babaev authored
      For aggregated fields from views/derived tables the possible adjustment
      of thd->lex->in_sum_func->max_arg_level in the function Item_field::fix_fields
      must be done before we leave the function.
      ec226e55
  15. 25 Sep, 2013 1 commit
  16. 13 Sep, 2013 1 commit
  17. 12 Sep, 2013 1 commit
  18. 12 Aug, 2013 2 commits
  19. 15 Jul, 2013 1 commit
    • Sergei Golubchik's avatar
      Fixes for innodb suite, merging tests from 5.6. · e1c76b80
      Sergei Golubchik authored
      Includes 5.6 changesets for:
      *****
      Fix for BUG#13489996 valgrind:conditional jump or move depends on uninitialised values-field_blob.
      blob_ptr_size was not initialized properly: remove this variable.
      *****
      Bug#14021323 CRASH IN FIELD::SET_NULL WHEN INSERTING ROWS TO NEW TABLE
      *****
      e1c76b80
  20. 10 Jul, 2013 2 commits
    • Alexander Barkov's avatar
      Adding support for the SQL-standard temporal literals. · d98584f5
      Alexander Barkov authored
      added:
        mysql-test/r/temporal_literal.result
        mysql-test/t/temporal_literal.test
      modified:
        client/mysqlbinlog.cc
        include/my_time.h
        mysql-test/r/cast.result
        mysql-test/r/partition_innodb.result
        mysql-test/t/cast.test
        mysql-test/t/partition_innodb.test
        sql-common/my_time.c
        sql/field.cc
        sql/item.cc
        sql/item.h
        sql/item_cmpfunc.cc
        sql/item_create.cc
        sql/item_create.h
        sql/item_strfunc.cc
        sql/item_timefunc.cc
        sql/item_timefunc.h
        sql/sql_select.cc
        sql/sql_time.cc
        sql/sql_time.h
        sql/sql_yacc.yy
        storage/spider/spd_db_mysql.cc
      d98584f5
    • Alexander Barkov's avatar
      Adding support for MySQL-5.6 temporal column types: · 5b0774ee
      Alexander Barkov authored
        TIME, DATETIME, TIMESTAMP
      
      
      added:
        mysql-test/r/type_temporal_mysql56.result
        mysql-test/std_data/mysql56datetime.MYD
        mysql-test/std_data/mysql56datetime.MYI
        mysql-test/std_data/mysql56datetime.frm
        mysql-test/std_data/mysql56time.MYD
        mysql-test/std_data/mysql56time.MYI
        mysql-test/std_data/mysql56time.frm
        mysql-test/std_data/mysql56timestamp.MYD
        mysql-test/std_data/mysql56timestamp.MYI
        mysql-test/std_data/mysql56timestamp.frm
        mysql-test/suite/rpl/r/rpl_temporal_mysql56.result
        mysql-test/suite/rpl/t/rpl_temporal_mysql56.test
        mysql-test/t/type_temporal_mysql56.test
        sql/compat56.cc
        sql/compat56.h
      modified:
        client/mysqlbinlog.cc
        include/my_time.h
        include/mysql.h.pp
        include/mysql_com.h
        mysql-test/r/statistics.result
        mysql-test/r/strict.result
        mysql-test/suite/binlog/r/binlog_mysqlbinlog_row_innodb.result
        mysql-test/suite/binlog/r/binlog_mysqlbinlog_row_myisam.result
        sql-common/my_time.c
        sql/CMakeLists.txt
        sql/field.cc
        sql/field.h
        sql/item.cc
        sql/item_strfunc.cc
        sql/item_sum.cc
        sql/item_timefunc.cc
        sql/log_event.cc
        sql/opt_range.cc
        sql/opt_table_elimination.cc
        sql/protocol.cc
        sql/rpl_utility.cc
        sql/rpl_utility.h
        sql/sql_partition.cc
        sql/sql_prepare.cc
        sql/sql_select.cc
        sql/sql_table.cc
        sql/table.cc
        storage/perfschema/pfs_engine_table.cc
      5b0774ee
  21. 03 Jul, 2013 1 commit
  22. 02 Jul, 2013 1 commit
  23. 15 Jun, 2013 1 commit
  24. 08 May, 2013 1 commit
    • Alexander Barkov's avatar
      The bug · e013bf9f
      Alexander Barkov authored
      MDEV-4489 "Replication of big5, cp932, gbk, sjis strings makes wrong values on slave"
      has been fixed.
      
      Problem:
      String constants of some Asian charsets (big5,cp932,gbk,sjis)
      can have backslash '\' (0x5C) in the second byte of multi-byte characters.
      Replicating of such constants using the standard '\'-escaping is dangerous.
      Therefore, constants of these charsets are replicated using hex notation:
      INSERT INTO t1 (a) VALUES (0x815C);
      
      However, 0xHHHH constants do not work well in some cases,
      because they can behave as strings and as numbers, depending on context
      (for example, depending on the data type of the column in an INSERT statement).
      
      This SQL script was not replicated correctly with statement-based replication:
      
      SET NAMES gbk;
      PREPARE STMT FROM 'INSERT INTO t1 (a) VALUES (?)';
      SET @A = '1';
      EXECUTE STMT USING @A;
      
      The INSERT statement was replicated as:
      INSERT INTO t1 (a) VALUES (0x31);
      
      '1' was correctly converted to the number 1 on master.
      But the 0x31 constant was treated as number 49 on slave.
      
      Fix:
      
      1. Binary log now uses X'HHHH' instead of 0xHHHH constants.
      2. The X'HHHH' constants now work always as strings, in all contexts.
      This is the SQL standard compliant behaviour.
      
      After the fix, the above statement is replicated as:
      INSERT INTO t1 (a) VALUES (X'31');
      X'31' is treated as string '1' on slave, and is correctly converted to 1.
      
      
      modified:
        @ mysql-test/r/ctype_cp932_binlog_stm.result
        @ mysql-test/r/select.result
        @ mysql-test/r/select_jcl6.result
        @ mysql-test/r/select_pkeycache.result
        @ mysql-test/r/user_var-binlog.result
        @ mysql-test/r/varbinary.result
        @ mysql-test/suite/binlog/r/binlog_stm_ctype_ucs.result
        @ mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result
        @ mysql-test/suite/rpl/r/rpl_charset_sjis.result
        @ mysql-test/suite/rpl/r/rpl_mdev382.result
        @ mysql-test/suite/rpl/t/rpl_charset_sjis.test
        @ mysql-test/t/ctype_cp932_binlog_stm.test
        @ mysql-test/t/select.test
        @ mysql-test/t/varbinary.test
          Adding and updating tests
      
        @ sql/item.cc
        @ sql/item.h
        @ sql/sql_yacc.yy
        @ sql/sql_lex.cc
          Splitting the implementations of X'HH' and 0xHH constants into two
          separate classes. Fixing the parser to distinguish the two syntaxes.
      
        @ sql/log_event.cc
          Using X'HH' instead of 0xHH for binary logging for string constants
          of the "dangerous" charsets.
      
        @ sql/sql_string.h
          Adding a helped method String::append_hex().
      e013bf9f
  25. 17 Apr, 2013 1 commit
  26. 12 Apr, 2013 1 commit
    • Alexey Botchkov's avatar
      MDEV-3917 multiple use locks (GET_LOCK) in one connection. · 1a600125
      Alexey Botchkov authored
          The patch contributed by Konstantin Osipov applied.
          Native comments:
            Implement multiple user-level locks per connection.
      
            GET_LOCK() function in MySQL allows a connection  to hold at most
            one user level lock. Taking a new lock automatically releases the
            old lock, if any.
      
            The limit of one lock per session existed since  early versions
            of MySQL didn't have a deadlock detector for SQL locks.
            MDL patches in MySQL 5.5 added a deadlock detector,
            so starting from 5.5 it became possible to take multiple locks
            in any order -- a deadlock, should it occur, would be detected
            and an error returned to the client which closed the wait chain.
      
            This is exactly what is done in this patch: ULLs are moved
            to use MDL subsystem.
      1a600125
  27. 07 Apr, 2013 1 commit
  28. 29 Mar, 2013 1 commit
  29. 28 Mar, 2013 1 commit
    • Nisha Gopalakrishnan's avatar
      BUG#11753852: IF() VALUES ARE EVALUATED DIFFERENTLY IN A · e85c90b9
      Nisha Gopalakrishnan authored
                    REGULAR SQL VS PREPARED STATEMENT
      
      Analysis:
      ---------
      
      When passing user variables as parameters to the
      prepared statements, the IF() function evaluation
      turns out to be incorrect.
      
      Consider the example:
      
      SET @var1='0.038687';
      SELECT @var1 , IF( @var1 = 0 , 1 ,@var1 ) AS sqlif ;
      +----------+----------+
      | @var1    | sqlif    |
      +----------+----------+
      | 0.038687 | 0.038687 |
      +----------+----------+
      
      Executing a prepared statement where the parameters are
      supplied:
      
      PREPARE fail_stmt FROM "SELECT ? ,
      IF( ? = 0 , 1 , ? ) AS ps_if_fail" ;
      EXECUTE fail_stmt USING @var1 ,@var1 , @var1 ;
      +----------+------------+
      | ?        | ps_if_fail |
      +----------+------------+
      | 0.038687 | 1          |
      +----------+------------+
      1 row in set (0.00 sec)
      
      In the regular statement or while executing the prepared
      statements without passing parameters, the decimal
      precision is set for the user variable of type string.
      The comparison function used for evaluation considered
      the precision while comparing the values.
      
      But while executing the prepared statement with the
      parameters supplied, the decimal precision was not
      set. Thus the comparison function chosen was different
      which looked at the absolute values for comparison.
      
      Fix:
      ----
      
      The fix is to set 'decimals' field of Item_param to the
      default value which is nothing but the maximum number of
      decimals(NOT_FIXED_DEC). This is set for cases where the
      strings are converted to the numeric form within certain
      functions. Thus the value is not rounded off during
      comparison, ensuring correct evaluation.
      e85c90b9
  30. 25 Mar, 2013 1 commit
  31. 17 Mar, 2013 2 commits
  32. 25 Feb, 2013 1 commit
  33. 23 Jan, 2013 1 commit
    • Gleb Shchepa's avatar
      Bug #11827369: ASSERTION FAILED: !THD->LEX->CONTEXT_ANALYSIS_ONLY · 19ea7c03
      Gleb Shchepa authored
      Some queries with the "SELECT ... FROM DUAL" nested subqueries
      failed with an assertion on debug builds.
      Non-debug builds were not affected.
      
      There were a few different issues with similar assertion
      failures on different queries:
      
      1. The first problem was related to the incomplete propagation
      of the "non-constant" item status from underlying subquery
      items to the outer item tree: in some cases non-constants were
      interpreted as constants and evaluated at the preparation stage
      (val_int() calls withing fix_fields() etc).
      
      Thus, the default implementation of Item_ref::const_item() from
      the Item parent class didn't take into account the "const_item"
      status of the referenced item tree -- it used the insufficient
      "used_tables() == 0" check instead. This worked in most cases
      since our "non-constant" functions like RAND() and SLEEP() set
      the RAND_TABLE_BIT in the used table map, so they aren't
      non-constant from Item_ref's "point of view". However, the
      "SELECT ... FROM DUAL" subquery may have an empty map of used
      tables, but at the same time subqueries are never "constant" at
      the context analysis stage (preparation, view creation etc).
      So, the non-contantness of such subqueries was missed.
      
      Fix: the Item_ref::const_item() function has been overloaded to
      take into account both (*ref)->const_item() status and tricky
      Item_ref::used_tables() return values, since the only
      (*ref)->const_item() call is not enough there.
      
      2. In some cases instead of the const_item() call we check a
      value of the Item::with_subselect field to recognize items
      with nested subqueries. However, the Item_ref class didn't
      propagate this value from the referenced item tree.
      
      Fix: Item::has_subquery() and Item_ref::has_subquery()
      functions have been backported from 5.6. All direct
      references to the with_subselect fields of nested items have
      been with the has_subquery() function call.
      
      3. The Item_func_regex class didn't propagate with_subselect
      as well, since it overloads the Item_func::fix_fields()
      function with insufficient fix_fields() implementation.
      
      Fix: the Item_func_regex::fix_fields() function has been
      modified to gather "constant" statuses from inner items.
      
      4. The Item_func_isnull::update_used_tables() function has
      a special branch for the underlying item where the maybe_null
      value is false: in this case it marks the Item_func_isnull
      as a "const_item" and sets the cached_value to false.
      However, the Item_func_isnull::val_int() was not in sync with
      update_used_tables(): it didn't take into account neither
      const_item_cache nor cached_value for the case of
      "args[0]->maybe_null == false optimization".
      As far as such an Item_func_isnull has "const_item() == true",
      it's ok to call Item_func_isnull::val_int() etc from outer
      items on preparation stage. In this case the server tried to
      call Item_func_isnull::args[0]->isnull(), and if the args[0]
      item contained a nested not-nullable subquery, it failed
      with an assertion.
      
      Fix: take the value of Item_func_isnull::const_item_cache into
      account in the val_int() function.
      
      5. The auxiliary Item_is_not_null_test class has a similar
      optimization in the update_used_tables() function as the
      Item_func_isnull class has, and the same issue in the val_int()
      function.
      In addition to that the Item_is_not_null_test::update_used_tables()
      doesn't update the const_item_cache value, so the "maybe_null"
      optimization is useless there. Thus, we missed some optimizations
      of cases like these (before and after the fix):
        <  <is_not_null_test>(a),
        ---
        >  <cache>(<is_not_null_test>(a)),
      or
        < having (<is_not_null_test>(a) and <is_not_null_test>(a))
        ---
        > having 1
      etc.
      
      Fix: update Item_is_not_null_test::const_item_cache in
      update_used_tables() and take in into account in val_int().
      19ea7c03
  34. 17 Jan, 2013 2 commits
    • Michael Widenius's avatar
      Don't reset maybe_null in update_used_tables(); This breaks ROLLUP · c65f9a19
      Michael Widenius authored
      This fixed failing test in group_by.test
      
      mysql-test/r/join_outer.result:
        Updated test case
      mysql-test/r/join_outer_jcl6.result:
        Updated test case
      sql/item.cc:
        Don't reset maybe_null in update_used_tables(); This breaks ROLLUP
      sql/item.h:
        Don't reset maybe_null in update_used_tables(); This breaks ROLLUP
      sql/item_cmpfunc.h:
        Don't reset maybe_null in update_used_tables(); This breaks ROLLUP
      c65f9a19
    • unknown's avatar
      backport of: · 8a296e6c
      unknown authored
      Don't reset maybe_null in update_used_tables(); This breaks ROLLUP
      This fixed failing test in group_by.test
      8a296e6c
  35. 07 Jan, 2013 1 commit
  36. 28 Dec, 2012 1 commit
    • unknown's avatar
      MDEV-3873 & MDEV-3876 & MDEV-3912 : Wrong result (extra rows) with ALL subquery · 6f26aac9
      unknown authored
      from a MERGE view.
      
      The problem was in the lost ability to be null for the table of a left join if it
      is a view/derived table.
      
      It hapenned because setup_table_map(), was called earlier then we merged
      the view or derived.
      
      Fixed by propagating new maybe_null flag during Item::update_used_tables().
      
      Change in join_outer.test and join_outer_jcl6.test appeared because
      IS NULL reported no used tables (i.e. constant) for argument which could not be
      NULL and new maybe_null flag was propagated for IS NULL argument (Item_field)
      because table the Item_field belonged to changed its maybe_null status.
      6f26aac9