1. 09 Sep, 2010 5 commits
    • Alexey Kopytov's avatar
      Manual merge of the fix for bug #54190 and the addendum patch · 637c7529
      Alexey Kopytov authored
      to 5.5 (removed one test case as it is no longer valid).
      637c7529
    • Alexey Kopytov's avatar
      Addendum patch for bug #54190. · f563a012
      Alexey Kopytov authored
      The patch caused some test failures when merged to 5.5 because,
      unlike 5.1, it utilizes Item_cache_row to actually cache row
      values. The problem was that Item_cache_row::bring_value()
      essentially did nothing. In particular, it did not update its
      null_value, so all Item_cache_row objects were always having
      their null_values set to TRUE. This went unnoticed previously,
      but now when Arg_comparator::compare_row() actually depends on
      the row's null_value to evaluate the comparison, the problem
      has surfaced.
      
      Fixed by calling the underlying item's bring_value() and
      updating null_value in Item_cache_row::bring_value().
      
      Since the problem also exists in 5.1 code (albeit hidden, since
      the relevant code is not used anywhere), the addendum patch is
      against 5.1.
      f563a012
    • Alexey Kopytov's avatar
      Automerge. · df198b5f
      Alexey Kopytov authored
      df198b5f
    • Alexey Kopytov's avatar
      Bug #54190: Comparison to row subquery produces incorrect · 9066714c
      Alexey Kopytov authored
                  result
      
      Row subqueries producing no rows were not handled as UNKNOWN
      values in row comparison expressions.
      
      That was a result of the following two problems:
      
      1. Item_singlerow_subselect did not mark the resulting row
      value as NULL/UNKNOWN when no rows were produced.
      
      2. Arg_comparator::compare_row() did not take into account that
      a whole argument may be NULL rather than just individual scalar
      values.
      
      Before bug#34384 was fixed, the above problems were hidden
      because an uninitialized (i.e. without any stored value) cached
      object would appear as NULL for scalar values in a row subquery
      returning an empty result. After the fix
      Arg_comparator::compare_row() would try to evaluate
      uninitialized cached objects.
      
      Fixed by removing the aforementioned problems.
      9066714c
    • Dmitry Shulga's avatar
      Fix mysql_client_test failure introduced by a patch for Bug#47485. · d88a11a7
      Dmitry Shulga authored
      The problem was that mysql_stmt_next_result() (new to 5.5)
      was not properly updated.
      d88a11a7
  2. 07 Sep, 2010 8 commits
    • Martin Hansson's avatar
      Merge of fix for Bug#51070. · 06b70326
      Martin Hansson authored
      06b70326
    • Martin Hansson's avatar
      Bug#51070: Query with a NOT IN subquery predicate returns a wrong result set · babebf9c
      Martin Hansson authored
            
      The EXISTS transformation has additional switches to catch the known corner
      cases that appear when transforming an IN predicate into EXISTS. Guarded
      conditions are used which are deactivated when a NULL value is seen in the
      outer expression's row. When the inner query block supplies NULL values,
      however, they are filtered out because no distinction is made between the
      guarded conditions; guarded NOT x IS NULL conditions in the HAVING clause that
      filter out NULL values cannot be de-activated in isolation from those that
      match values or from the outer expression or NULL's.
      
      The above problem is handled by making the guarded conditions remember whether
      they have rejected a NULL value or not, and index access methods are taking
      this into account as well. 
      
      The bug consisted of 
      
      1) Not resetting the property for every nested loop iteration on the inner
         query's result.
      
      2) Not propagating the NULL result properly from inner query to IN optimizer.
      
      3) A hack that may or may not have been needed at some point. According to a
         comment it was aimed to fix #2 by returning NULL when FALSE was actually
         the result. This caused failures when #2 was properly fixed. The hack is
         now removed.
      
      The fix resolves all three points.
      babebf9c
    • Dmitry Shulga's avatar
      Auto-merge from mysql-5.1-bugteam. · 41709256
      Dmitry Shulga authored
      41709256
    • Dmitry Shulga's avatar
      Fixed bug #55421 - Protocol::end_statement(): Assertion `0' on · 70807d14
      Dmitry Shulga authored
      multi-table UPDATE IGNORE.
      The problem was that if there was an active SELECT statement
      during trigger execution, an error risen during the execution
      may cause a crash. The fix is to temporary reset LEX::current_select
      before trigger execution and restore it afterwards. This way
      errors risen during the trigger execution are processed as
      if there was no active SELECT.
      70807d14
    • Martin Hansson's avatar
    • Martin Hansson's avatar
      Bug#54543: update ignore with incorrect subquery leads to assertion failure: · 3d5b9792
      Martin Hansson authored
      inited==INDEX
      
      When an error occurs while sending the data in a temporary table there was no
      cleanup performed. This caused a failed assertion in the case when different
      access methods were used for populating the table vs. retrieving the data from
      the table if IGNORE was specified and sql_safe_updates = 0. In this case
      execution continues, but the handler expects to continue with the access
      method used for row retrieval.
      
      Fixed by doing the cleanup even if errors occur.
      3d5b9792
    • Dmitry Shulga's avatar
      Auto-merge from mysql-5.1-bugteam. · d439036a
      Dmitry Shulga authored
      d439036a
    • Dmitry Shulga's avatar
      Fixed bug #47485 - mysql_store_result returns a not NULL result set · 14dbc7e4
      Dmitry Shulga authored
      for a prepared statement.
      14dbc7e4
  3. 06 Sep, 2010 4 commits
  4. 03 Sep, 2010 1 commit
  5. 01 Sep, 2010 3 commits
    • 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
    • Alexander Nozdrin's avatar
      Auto-merge from mysql-5.5. · f8f23158
      Alexander Nozdrin authored
      f8f23158
    • Alexander Nozdrin's avatar
      Auto-merge from mysql-5.5-stage. · afe9d44c
      Alexander Nozdrin authored
      afe9d44c
  6. 31 Aug, 2010 2 commits
  7. 30 Aug, 2010 12 commits
  8. 28 Aug, 2010 1 commit
  9. 27 Aug, 2010 4 commits
    • Vasil Dimov's avatar
      Merge mysql-5.1-innodb -> mysql-5.1-bugteam · 74c32d69
      Vasil Dimov authored
      74c32d69
    • Marc Alff's avatar
      local merge · 73570819
      Marc Alff authored
      73570819
    • Sergey Vojtovich's avatar
      Merge 5.1-bugteam to 5.5-merge. · ab241457
      Sergey Vojtovich authored
      ab241457
    • 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