1. 25 Aug, 2010 1 commit
  2. 24 Aug, 2010 2 commits
    • Alexey Kopytov's avatar
      Automerge. · 947c7f30
      Alexey Kopytov authored
      947c7f30
    • Alexey Kopytov's avatar
      Bug #55568: user variable assignments crash server when used · 0e74ac50
      Alexey Kopytov authored
                  within query
      
      The server could crash after materializing a derived table
      which requires a temporary table for grouping.
      
      When destroying the temporary table used to execute a query for
      a derived table, JOIN::destroy() did not clean up Item_fields
      pointing to fields in the temporary table. This led to
      dereferencing a dangling pointer when printing out the items
      tree later in the outer SELECT.
      
      The solution is an addendum to the patch for bug37362: in
      addition to cleaning up items in tmp_all_fields3, do the same
      for items in tmp_all_fields1, since now we have an example
      where this is necessary.
      0e74ac50
  3. 20 Aug, 2010 7 commits
    • Georgi Kodinov's avatar
      merge · 8f81ceeb
      Georgi Kodinov authored
      8f81ceeb
    • Georgi Kodinov's avatar
      merge · 2488c65a
      Georgi Kodinov authored
      2488c65a
    • Georgi Kodinov's avatar
      merge · 86720c49
      Georgi Kodinov authored
      86720c49
    • Georgi Kodinov's avatar
      merge · bbaad888
      Georgi Kodinov authored
      bbaad888
    • Georgi Kodinov's avatar
      merge · f1517f48
      Georgi Kodinov authored
      f1517f48
    • Georgi Kodinov's avatar
      merge · f2adff5d
      Georgi Kodinov authored
      f2adff5d
    • Georgi Kodinov's avatar
      Bug #55826: create table .. select crashes with when · 3b36a677
      Georgi Kodinov authored
        KILL_BAD_DATA is returned
      
      Two problems discovered with the LEAST()/GREATEST() 
      functions:
      1. The check for a null value should happen even 
      after the second call to val_str() in the args. This is
      important because two subsequent calls to the same
      Item::val_str() may yield different results.
      Fixed by checking for NULL value before dereferencing
      the string result.
      
      2. While looping over the arguments and evaluating them 
      the loop should stop if there was an error evaluating so far
      or the statement was killed. Fixed by checking for error
      and bailing out.
      3b36a677
  4. 19 Aug, 2010 3 commits
  5. 18 Aug, 2010 1 commit
    • '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
  6. 16 Aug, 2010 1 commit
  7. 13 Aug, 2010 3 commits
    • Georgi Kodinov's avatar
      Bug #55615 and bug #55564 · a5575096
      Georgi Kodinov authored
      An user assignment variable expression that's 
      evaluated in a logical expression context 
      (Item::val_bool()) can be pre-calculated in a 
      temporary table for GROUP BY.
      However when the expression value is used after the
      temp table creation it was re-evaluated instead of
      being read from the temp table due to a missing 
      val_bool_result() method.
      Fixed by implementing the method.
      a5575096
    • 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
  8. 11 Aug, 2010 1 commit
  9. 10 Aug, 2010 2 commits
  10. 09 Aug, 2010 1 commit
    • Jon Olav Hauglid's avatar
      Bug #54106 assert in Protocol::end_statement, · cc3be1ae
      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.
      cc3be1ae
  11. 06 Aug, 2010 4 commits
  12. 05 Aug, 2010 4 commits
    • Georgi Kodinov's avatar
      82e2ca01
    • Martin Hansson's avatar
      Bug#54568: create view cause Assertion failed: 0, · f7799695
      Martin Hansson authored
      file .\item_subselect.cc, line 836
      
      IN quantified predicates are never executed directly. They are rather wrapped
      inside nodes called IN Optimizers (Item_in_optimizer) which take care of the
      execution. However, this is not done during query preparation. Unfortunately
      the LIKE predicate pre-evaluates constant right-hand side arguments even
      during name resolution. Likely this is meant as an optimization.
      
      Fixed by not pre-evaluating LIKE arguments in view prepare mode.
      f7799695
    • Sunny Bains's avatar
      Fix Bug #55277 - Failing assertion: auto_inc > 0 · 6c0f9301
      Sunny Bains authored
      Handle overflow when reading value from SELECT MAX(C) FROM T;
      
      Call ha_innobase::info() after initializing the autoinc value
      in ha_innobase::open().
      
      Fix for both the builtin and plugin.
      
      rb://402
      6c0f9301
    • Sunny Bains's avatar
      Fix bug# 55543 - InnoDB Plugin: Signal 6: Assertion failure in file fil/fil0fil.c line 4306 · e19a4942
      Sunny Bains authored
      The bug is due to a double delete of a BLOB, once via:
      
          rollback -> btr_cur_pessimistic_delete()
      
      and the second time via purge.
      
      The bug is in row_upd_clust_rec_by_insert(). There we relinquish ownership
      of the non-updated BLOB columns in btr_cur_mark_extern_inherited_fields()
      before building the row entry that will be inserted and whose contents will
      be logged in the UNDO log. However, we don't set the BLOB column later to
      INHERITED so that a possible rollback will not free the original row's
      non-updated BLOB entries. This is because the condition that checks for
      that is in :
      
      	if (node->upd_ext) {}.
      
      node->upd_ext is non-NULL only if a BLOB column was updated and that column
      is part of some key ordering (see row_upd_replace()). This results in the
      non-update BLOB columns being deleted during a rollback and subsequently by
      purge again.
      
      rb://413
      e19a4942
  13. 04 Aug, 2010 5 commits
  14. 03 Aug, 2010 5 commits