1. 07 Sep, 2010 2 commits
  2. 01 Sep, 2010 1 commit
    • Magne Mahre's avatar
      Bug#39932 "create table fails if column for FK is in different · 24fc7ca4
      Magne Mahre authored
                case than in corr index".
            
      Server was unable to find existing or explicitly created supporting
      index for foreign key if corresponding statement clause used field
      names in case different than one used in key specification and created
      yet another supporting index.
      In cases when name of constraint (and thus name of generated index)
      was the same as name of existing/explicitly created index this led
      to duplicate key name error.
            
      The problem was that unlike all other code Key_part_spec::operator==()
      compared field names in case sensitive fashion. As result routines
      responsible for getting rid of redundant generated supporting indexes
      for foreign key were not working properly for versions of field names
      using different cases.
      
      (backported from mysql-trunk)
      24fc7ca4
  3. 24 Aug, 2010 1 commit
  4. 30 Aug, 2010 5 commits
  5. 27 Aug, 2010 3 commits
    • Vasil Dimov's avatar
      Merge mysql-5.1-innodb -> mysql-5.1-bugteam · 74c32d69
      Vasil Dimov authored
      74c32d69
    • Alexey Kopytov's avatar
      Bug #54465: assert: field_types == 0 || field_types[field_pos] · b409a221
      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.
      b409a221
    • Ramil Kalimullin's avatar
      Fix for bug #54253: memory leak when using I_S plugins w/o deinit method · 1087cfc4
      Ramil Kalimullin authored
      Free memory allocated by the server for all plugins,
      with or without deinit() method.
      1087cfc4
  6. 26 Aug, 2010 5 commits
  7. 25 Aug, 2010 4 commits
  8. 24 Aug, 2010 2 commits
    • Alexey Kopytov's avatar
      Bug #54802: 'NOT BETWEEN' evaluation is incorrect · 756076bd
      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.
      756076bd
    • Marko Mäkelä's avatar
      Bug#55832: selects crash too easily when innodb_force_recovery>3 · ce7d6a28
      Marko Mäkelä authored
      dict_update_statistics_low(): Create bogus statistics for those
      indexes that cannot be accessed because of the innodb_force_recovery
      setting.
      
      ha_innobase::info(): Calculate statistics for each index, even if
      innodb_force_recovery is set. Fill in bogus data for those indexes
      that are not accessed because of the innodb_force_recovery setting.
      ce7d6a28
  9. 23 Aug, 2010 1 commit
    • Marko Mäkelä's avatar
      Bug#55832: selects crash too easily when innodb_force_recovery>3 · 109893da
      Marko Mäkelä authored
      dict_update_statistics_low(): Create bogus statistics for those
      indexes that cannot be accessed because of the innodb_force_recovery
      setting.
      
      ha_innobase::info(): Calculate statistics for each index, even if
      innodb_force_recovery is set. Fill in bogus data for those indexes
      that are not accessed because of the innodb_force_recovery setting.
      109893da
  10. 20 Aug, 2010 7 commits
  11. 19 Aug, 2010 3 commits
  12. 18 Aug, 2010 2 commits
    • Marko Mäkelä's avatar
      Bug#55626: MIN and MAX reading a delete-marked record from secondary index · d3a7ef99
      Marko Mäkelä authored
      Remove a bogus debug assertion that triggered the bug.
      Add assertions precisely where records must not be delete-marked.
      And a comment to clarify when the record is allowed to be delete-marked.
      d3a7ef99
    • 's avatar
      WL#5370 Keep forward-compatibility when changing · b766a51f
      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.
      b766a51f
  13. 17 Aug, 2010 2 commits
  14. 13 Aug, 2010 2 commits
    • Georgi Kodinov's avatar
      Bug #55580 : segfault in read_view_sees_trx_id · 12f7d57d
      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.
      12f7d57d
    • Georgi Kodinov's avatar
      Bug #55565: debug assertion when ordering by expressions with user · b6e3adf1
      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.
      b6e3adf1