1. 27 Aug, 2010 1 commit
    • Alexey Kopytov's avatar
      Bug #54465: assert: field_types == 0 || field_types[field_pos] · d7d0f639
      Alexey Kopytov authored
                  == MYSQL_TYPE_LONGLONG
      
      A MIN/MAX() function with a subquery as its argument could lead
      to a debug assertion on debug builds or wrong data on release
      ones.
      
      The problem was a combination of the following factors:
      
      - Item_sum_hybrid::fix_fields() might use the argument
      (args[0]) to calculate 'hybrid_field_type' which was later used
      to decide how the data should be sent to the client.
      
      - Item_sum::make_field() might use the argument again to
      calculate the field's type when sending result set metadata to
      the client.
      
      - The argument could be changed in between these two calls via
        Item::set_arg() leading to inconsistent metadata being
        reported.
      
      Here is what was happening for the bug's test case:
      
      1. Item_sum_hybrid::fix_fields() calculates hybrid_field_type
      as MYSQL_TYPE_LONGLONG based on args[0] which is an
      Item::SUBSELECT_ITEM at that time.
      
      2. A temporary table is created to execute the
      query. create_tmp_field_from_item() creates a Field_long object
      according to the subselect's max_length.
      
      3. The subselect item in Item_sum_hybrid is replaced by the
      Item_field object referencing the newly created Field_long.
      
      4. Item_sum::make_field() rightfully returns the
      MYSQL_TYPE_LONG type when calculating the result set metadata.
      
      5. When sending the actual data, Item::send() relies on the
      virtual field_type() function which in our case returns
      previously calculated hybrid_field_type == MYSQL_TYPE_LONGLONG.
      
      It looks like the only solution is to never refer to the
      argument's metadata after the result metadata has been
      calculated in fix_fields(), since the argument itself may be
      different by then. In this sense, Item_sum::make_field() should
      never be used, because it may rely on the argument's metadata
      and is only called after fix_fields(). The "default"
      implementation in Item::make_field() should be used instead as
      it relies only on field_type(), but not on the argument's type.
      
      Fixed by removing Item_sum::make_field() so that the superclass
      implementation Item::make_field() is always used.
      
      mysql-test/r/func_group.result:
        Added a test case for bug #54465.
      mysql-test/t/func_group.test:
        Added a test case for bug #54465.
      sql/item_sum.cc:
        Removed Item_sum::make_field() so that the superclass
        implementation Item::make_field() is always used.
      sql/item_sum.h:
        Removed Item_sum::make_field() so that the superclass
        implementation Item::make_field() is always used.
      d7d0f639
  2. 26 Aug, 2010 3 commits
    • Alexey Kopytov's avatar
      Automerge. · 27d5b6e5
      Alexey Kopytov authored
      27d5b6e5
    • Sergey Vojtovich's avatar
      d1fb4ba2
    • Evgeny Potemkin's avatar
      Bug #55656: mysqldump can be slower after bug 39653 fix. · b4dc600a
      Evgeny Potemkin authored
      After fix for bug 39653 the shortest available secondary index was used for
      full table scan. Primary clustered key was used only if no secondary index
      can be used. However, when chosen secondary index includes all fields of the
      table being scanned it's better to use primary index since the amount of
      data to scan is the same but the primary index is clustered.
      Now the find_shortest_key function takes this into account.
      
      
      mysql-test/suite/innodb/r/innodb_mysql.result:
        Added a test case for the bug#55656.
      mysql-test/suite/innodb/t/innodb_mysql.test:
        Added a test case for the bug#55656.
      sql/sql_select.cc:
        Bug #55656: mysqldump can be slower after bug #39653 fix.
        The find_shortest_key function now prefers clustered primary key
        if found secondary key includes all fields of the table.
      b4dc600a
  3. 25 Aug, 2010 4 commits
  4. 24 Aug, 2010 1 commit
    • Alexey Kopytov's avatar
      Bug #54802: 'NOT BETWEEN' evaluation is incorrect · e7b26882
      Alexey Kopytov authored
      Queries involving predicates of the form "const NOT BETWEEN
      not_indexed_column AND indexed_column" could return wrong data
      due to incorrect handling by the range optimizer.
      
      For "c NOT BETWEEN f1 AND f2" predicates, get_mm_tree()
      produces a disjunction of the SEL_ARG trees for "f1 > c" and
      "f2 < c". If one of the trees is empty (i.e. one of the
      arguments is not sargable) the resulting tree should be empty
      as well, since the whole expression in this case is not
      sargable.
      
      The above logic is implemented in get_mm_tree() as follows. The
      initial state of the resulting tree is NULL (aka empty). We
      then iterate through arguments and compute the corresponding
      SEL_ARG tree (either "f1 > c" or "f2 < c"). If the resulting
      tree is NULL, it is simply replaced by the generated
      tree. Otherwise it is replaced by a disjunction of itself and
      the generated tree. The obvious flaw in this implementation is
      that if the first argument is not sargable and thus produces a
      NULL tree, the resulting tree will simply be replaced by the
      tree for the second argument. As a result, "c NOT BETWEEN f1
      AND f2" will end up as just "f2 < c".
      
      Fixed by adding a check so that when the first argument
      produces an empty tree for the NOT BETWEEN case, the loop is
      aborted with an empty tree as a result. The whole idea of using
      a loop for 2 arguments does not make much sense, but it was
      probably used to avoid code duplication for several BETWEEN
      variants.
      e7b26882
  5. 20 Aug, 2010 4 commits
  6. 19 Aug, 2010 3 commits
  7. 18 Aug, 2010 1 commit
    • unknown's avatar
      WL#5370 Keep forward-compatibility when changing · 9d681150
      unknown authored
              'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour
      BUG#55474, BUG#55499, BUG#55598, BUG#55616 and BUG#55777 are fixed
      in this patch too.
      
      This is the 5.1 part.
      It implements:
      - if the table exists, binlog two events: CREATE TABLE IF NOT EXISTS
        and INSERT ... SELECT
      
      - Insert nothing and binlog nothing on master if the existing object
        is a view. It only generates a warning that table already exists.
      
      
      mysql-test/r/trigger.result:
        Ather this patch, 'CREATE TABLE IF NOT EXISTS ... SELECT' will not
        insert anything if the creating table already exists and is a view.
      sql/sql_class.h:
        Declare virtual function write_to_binlog() for select_insert.
        It's used to binlog 'create select'
      sql/sql_insert.cc:
        Implement write_to_binlog();
        Use write_to_binlog() instead of binlog_query() to binlog the statement.
        if the table exists, binlog two events: CREATE TABLE IF NOT EXISTS
        and INSERT ... SELECT
      sql/sql_lex.h:
        Declare create_select_start_with_brace and create_select_pos.
        They are helpful for binlogging 'create select'
      sql/sql_parse.cc:
        Do nothing on master if the existing object is a view.
      sql/sql_yacc.yy:
        Record the relative postion of 'SELECT' in the 'CREATE ...SELECT' statement.
        Record whether there is a '(' before the 'SELECT' clause.
      9d681150
  8. 13 Aug, 2010 2 commits
    • Georgi Kodinov's avatar
      Bug #55580 : segfault in read_view_sees_trx_id · 790852c0
      Georgi Kodinov authored
      The server was not checking for errors generated during
      the execution of Item::val_xxx() methods when copying
      data to the group, order, or distinct temp table's row.
      Fixed by extending the copy_funcs() to return an error
      code and by checking for that error code on the places
      copy_funcs() is called. 
      Test case added.
      790852c0
    • Georgi Kodinov's avatar
      Bug #55565: debug assertion when ordering by expressions with user · 8b25c0e4
      Georgi Kodinov authored
      variable assignments
      
      The assert() that is firing is checking if expressions that can't be
      null return a NULL when evaluated.
      MAKEDATE() function can return NULL if the second argument is 
      less then or equal to 0. Thus its nullability depends not only on 
      the nullability of its arguments but also on their values.
      Fixed by (overoptimistically) setting MAKEDATE() to be nullable 
      despite the nullability of its arguments.
      Test added.
      Had to update one test result to reflect the metadata change.
      8b25c0e4
  9. 11 Aug, 2010 1 commit
  10. 10 Aug, 2010 2 commits
  11. 09 Aug, 2010 1 commit
    • Jon Olav Hauglid's avatar
      Bug #54106 assert in Protocol::end_statement, · d62bfebc
      Jon Olav Hauglid authored
                 INSERT IGNORE ... SELECT ... UNION SELECT ...
      
      This assert was triggered by INSERT IGNORE ... SELECT. The assert checks that a
      statement either sends OK or an error to the client. If the bug was triggered
      on release builds, it caused OK to be sent to the client instead of the correct
      error message (in this case ER_FIELD_SPECIFIED_TWICE).
      
      The reason the assert was triggered, was that lex->no_error was set to TRUE
      during JOIN::optimize() because of IGNORE. This causes all errors to be ignored.
      However, not all errors can be ignored. Some, such as ER_FIELD_SPECIFIED_TWICE
      will cause the INSERT to fail no matter what. But since lex->no_error was set,
      the critical errors were ignored, the INSERT failed and neither OK nor the
      error message was sent to the client.
      
      This patch fixes the problem by temporarily turning off lex->no_error in
      places where errors cannot be ignored during processing of INSERT ... SELECT.
      
      Test case added to insert.test.
      d62bfebc
  12. 06 Aug, 2010 3 commits
  13. 05 Aug, 2010 2 commits
  14. 04 Aug, 2010 3 commits
  15. 03 Aug, 2010 5 commits
    • Georgi Kodinov's avatar
      Bug #42144: plugin_load fails · 5eeb6488
      Georgi Kodinov authored
      The enum system variables were handled inconsistently 
      as ints, unsigned int and unsigned long on various places.
      This caused problems on platforms on which 
      sizeof(int) != sizeof(long).
      Fixed by homogenizing the type of the enum variables
      to unsigned int, since it's size compatible with the C enum
      type. 
      Removed the test from the experimental list.
      5eeb6488
    • Bjorn Munch's avatar
      Bug #55582 mtr root detection (and if-expression execution) broken · 5e92df6e
      Bjorn Munch authored
      if() treated any non-numeric string as false
      Fixed to treat those as true instead
      Added some test cases
      Fixed missing $ in variable name in include/mix2.inc
      5e92df6e
    • Alfranio Correia's avatar
    • unknown's avatar
      Bug #34283 mysqlbinlog leaves tmpfile after termination if binlog contains load data infile · 60ab046a
      unknown authored
      Post fix
      
      mysql-test/t/mysqlbinlog.test:
        Updated for Bug#34283
      60ab046a
    • unknown's avatar
      Bug #34283 mysqlbinlog leaves tmpfile after termination if binlog contains load data infile · bcb3170c
      unknown authored
      With statement- or mixed-mode logging, "LOAD DATA INFILE" queries
      are written to the binlog using special types of log events.
      When mysqlbinlog reads such events, it re-creates the file in a
      temporary directory with a generated filename and outputs a
      "LOAD DATA INFILE" query where the filename is replaced by the
      generated file. The temporary file is not deleted by mysqlbinlog
      after termination.
      
      To fix the problem, in mixed mode we go to row-based. In SBR, we
      document it to remind user the tmpfile is left in a temporary
      directory.
      
      
      
      
      mysql-test/extra/rpl_tests/rpl_loaddata.test:
        Updated for Bug#34283
      mysql-test/suite/binlog/r/binlog_mixed_load_data.result:
        Test result for BUG#34283.
      mysql-test/suite/binlog/t/binlog_killed_simulate.test:
        Updated for Bug#34283
      mysql-test/suite/binlog/t/binlog_mixed_load_data.test:
        Added the test file to verify that 'load data infile...' statement
        will go to row-based in mixed mode.
      mysql-test/suite/binlog/t/binlog_stm_blackhole.test:
        Updated for Bug#34283
      mysql-test/suite/rpl/r/rpl_innodb_mixed_dml.result:
        Updated for Bug#34283
      mysql-test/suite/rpl/t/rpl_loaddata_fatal.test:
        Updated for Bug#34283
      mysql-test/suite/rpl/t/rpl_loaddata_map.test:
        Updated for Bug#34283
      mysql-test/suite/rpl/t/rpl_slave_load_remove_tmpfile.test:
        Updated for Bug#34283
      mysql-test/suite/rpl/t/rpl_stm_log.test:
        Updated for Bug#34283
      sql/sql_load.cc:
        Added code to go to row-based in mixed mode for
        'load data infile ...' statement
      bcb3170c
  16. 02 Aug, 2010 4 commits
    • Alfranio Correia's avatar
      BUG#55625 RBR breaks on failing 'CREATE TABLE' · f62e89fa
      Alfranio Correia authored
      A CREATE...SELECT that fails is written to the binary log if a non-transactional
      statement is updated. If the logging format is ROW, the CREATE statement and the
      changes are written to the binary log as distinct events and by consequence the
      created table is not rolled back in the slave.
      
      In this patch, we opted to let the slave goes out of sync by not writting to the
      binary log the CREATE statement. We do this by simply reseting the binary log's
      cache.
      
      mysql-test/suite/rpl/r/rpl_drop.result:
        Added a test case.
      mysql-test/suite/rpl/t/rpl_drop.test:
        Added a test case.
      sql/log.cc:
        Introduced a function to clean up the cache.
      sql/log.h:
        Introduced a function to clean up the cache.
      sql/sql_insert.cc:
        Cleaned up the binary log cache if a CREATE...SELECT fails.
      f62e89fa
    • Bjorn Munch's avatar
      Bug #55597 MTR: Restart the server, from within the test case, with new CLI options. · f3d4e72c
      Bjorn Munch authored
      The expect file can now include "restart:<server options>"
      Also drop check-testcase if this has been done
      Added comment explaining the restart: syntax
      f3d4e72c
    • Georgi Kodinov's avatar
      merge · c65e99e0
      Georgi Kodinov authored
      c65e99e0
    • Georgi Kodinov's avatar
      4f738e9b