An error occurred fetching the project authors.
  1. 09 Nov, 2010 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #668644. · 6b67bafc
      Igor Babaev authored
      The pushdown condition for the sorted table in a query can be complemented
      by the conditions from HAVING. This transformation is done in JOIN::exec
      pretty late after the original pushdown condition have been saved in the
      field pre_idx_push_select_cond for the sorted table. So this field must
      be updated after the inclusion of the condition from HAVING.
      
      6b67bafc
  2. 26 Aug, 2010 1 commit
    • 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. 20 Aug, 2010 1 commit
    • Georgi Kodinov's avatar
      Bug #55826: create table .. select crashes with when · 6bea77ae
      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.
      6bea77ae
  4. 13 Aug, 2010 1 commit
    • 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
  5. 07 Jul, 2010 1 commit
    • Jon Olav Hauglid's avatar
      Bug #54117 crash in thr_multi_unlock, temporary table · 223f42b7
      Jon Olav Hauglid authored
      This crash occured after ALTER TABLE was used on a temporary
      transactional table locked by LOCK TABLES. Any later attempts to
      execute LOCK/UNLOCK TABLES, caused the server to crash.
      
      The reason for the crash was the list of locked tables would
      end up having a pointer to a free'd table instance. This happened
      because ALTER TABLE deleted the table without also removing the
      table reference from the locked tables list.
      
      This patch fixes the problem by making sure ALTER TABLE also
      removes the table from the locked tables list.
      
      Test case added to innodb_mysql.test.
      223f42b7
  6. 14 Jun, 2010 1 commit
  7. 09 Jun, 2010 1 commit
    • Sergey Glukhov's avatar
      Bug#38999 valgrind warnings for update statement in function compare_record() · 60a66c45
      Sergey Glukhov authored
      Valgrind warning happpens because of uninitialized null bytes.
      In row_sel_push_cache_row_for_mysql() function we fill fetch cache
      with necessary field values, row_sel_store_mysql_rec() is called
      for this and leaves null bytes untouched.
      Later row_sel_pop_cached_row_for_mysql() rewrites table record
      buffer with uninited null bytes. We can see the problem from the
      test case:
      At 'SELECT...' we call row_sel_push...->row_sel_store...->row_sel_pop_cached...
      chain which rewrites table->record[0] buffer with uninitialized null bytes.
      When we call 'UPDATE...' statement, compare_record uses this buffer and
      valgrind warning occurs.
      The fix is to init null bytes with default values.
      
      
      mysql-test/suite/innodb/r/innodb_mysql.result:
        test case
      mysql-test/suite/innodb/t/innodb_mysql.test:
        test case
      mysql-test/t/ps_3innodb.test:
        enable valgrind testing
      storage/innobase/row/row0sel.c:
        init null bytes with default values as they might be
        left uninitialized in some cases and these uninited bytes
        might be copied into mysql record buffer that leads to
        valgrind warnings on next use of the buffer.
      60a66c45
  8. 03 Jun, 2010 1 commit
  9. 26 May, 2010 1 commit
    • Igor Babaev's avatar
      Changed the fixes for the following bugs: · d120c5b5
      Igor Babaev authored
      Bug #39022: completed
      Bug #39653: reverted as invalid
      Bug #45640: ameliorated, simplified, optimized
      Bug #48483: completed
      Bug #49324: improved
      Bug #51242/52336: reverted, applied a real fix.
      d120c5b5
  10. 25 May, 2010 1 commit
    • Alexey Kopytov's avatar
      Bug #53830: !table || (!table->read_set || · 1d0acc77
      Alexey Kopytov authored
                   bitmap_is_set(table->read_set, field_index))
      
      UPDATE on an InnoDB table modifying the same index that is used
      to satisfy the WHERE condition could trigger a debug assertion
      under some circumstances.
      
      Since for engines with the HA_PRIMARY_KEY_IN_READ_INDEX flag
      set results of an index scan on a secondary index are appended
      by the primary key value, if a query involves only columns from
      the primary key and a secondary index, the latter is considered
      to be covering.
      
      That tricks mysql_update() to mark for reading only columns
      from the secondary index when it does an index scan to retrieve
      rows to update in case a part of that key is also being
      updated. However, there may be other columns in WHERE that are
      part of the primary key, but not the secondary one.
      
      What we actually want to do in this case is to add index
      columns to the existing WHERE columns bitmap rather than
      replace it.
      
      mysql-test/r/innodb_mysql.result:
        Test case for bug #53830.
      mysql-test/t/innodb_mysql.test:
        Test case for bug #53830.
      sql/sql_update.cc:
        Add index columns to the read_set bitmap, don't replace it.
      sql/table.cc:
        Added a new add_read_columns_used_by_index() function to 
        st_table.
      sql/table.h:
        Added a new add_read_columns_used_by_index() function to 
        st_table.
      1d0acc77
  11. 07 May, 2010 1 commit
  12. 03 May, 2010 1 commit
    • unknown's avatar
      Fixed bug #53334. · 50ddf3c1
      unknown authored
      The fix actually reverts the change introduced by the patch
      for bug 51494
      The fact is that the patch for bug 52177 fixes bug 51194 as well.
      50ddf3c1
  13. 28 Apr, 2010 1 commit
    • Georgi Kodinov's avatar
      Bug #47453: InnoDB incorrectly changes TIMESTAMP columns when JOINed · 4d0e9957
      Georgi Kodinov authored
      during an UPDATE
      
      Extended the fix for bug 29310 to multi-table update:
      
      When a table is being updated it has two set of fields - fields required for
      checks of conditions and fields to be updated. A storage engine is allowed
      not to retrieve columns marked for update. Due to this fact records can't
      be compared to see whether the data has been changed or not. This makes the
      server always update records independently of data change.
        
      Now when an auto-updatable timestamp field is present and server sees that
      a table handle isn't going to retrieve write-only fields then all of such
      fields are marked as to be read to force the handler to retrieve them.
      4d0e9957
  14. 17 Mar, 2010 1 commit
    • Georgi Kodinov's avatar
      Bug #49838: DROP INDEX and ADD UNIQUE INDEX for same index may corrupt · ae49d971
      Georgi Kodinov authored
         definition at engine
      
      If a single ALTER TABLE contains both DROP INDEX and ADD INDEX using 
      the same index name (a.k.a. index modification) we need to disable 
      in-place alter table because we can't ask the storage engine to have 
      two copies of the index with the same name even temporarily (if we 
      first do the ADD INDEX and then DROP INDEX) and we can't modify 
      indexes that are needed by e.g. foreign keys if we first do 
      DROP INDEX and then ADD INDEX.
      Fixed the problem by disabling in-place ALTER TABLE for these cases.
      ae49d971
  15. 11 Mar, 2010 1 commit
    • unknown's avatar
      MWL#68 Subquery optimization: Efficient NOT IN execution with NULLs · 3d2a7460
      unknown authored
      This patch does three things:
      - It adds the possibility to force the execution of top-level [NOT] IN
        subquery predicates via the IN=>EXISTS transformation. This is done by
        setting both optimizer switches partial_match_rowid_merge and
        partial_match_table_scan to "off".
      - It adjusts all test cases where the complete optimizer_switch is
        selected because now we have two more switches.
      - For those test cases where the plan changes because of the new available
        strategies, we switch off both partial match strategies in order to
        force the "old" IN=>EXISTS strategy. This is done because most of these
        test cases specifically test bugs in this strategy.
      
      sql/opt_subselect.cc:
        Adds the possibility to force the execution of top-level [NOT] IN
        subquery predicates via the IN=>EXISTS transformation. This is done by
        setting both optimizer switches partial_match_rowid_merge and
        partial_match_table_scan to "off".
      3d2a7460
  16. 05 Mar, 2010 1 commit
    • Gleb Shchepa's avatar
      Bug #39653: find_shortest_key in sql_select.cc does not · 63a88e13
      Gleb Shchepa authored
                  consider clustered primary keys
      
      Choosing a shortest index for the covering index scan,
      the optimizer ignored the fact, that the clustered primary
      key read involves whole table data.
      
      The find_shortest_key function has been modified to
      take into account that fact that a clustered PK has a
      longest key of possible covering indices.
      
      
      mysql-test/r/innodb_mysql.result:
        Test case for bug #39653.
      mysql-test/t/innodb_mysql.test:
        Test case for bug #39653.
      sql/sql_select.cc:
        Bug #39653: find_shortest_key in sql_select.cc does not
                    consider clustered primary keys
        
        The find_shortest_key function has been modified to
        take into account that fact that a clustered PK has a
        longest key of possible covering indices.
      63a88e13
  17. 26 Feb, 2010 1 commit
    • Evgeny Potemkin's avatar
      Bug#50843: Filesort used instead of clustered index led to · 2d4db52e
      Evgeny Potemkin authored
      performance degradation.
      
      Filesort + join cache combination is preferred to full index scan because it
      is usually faster. But it's not the case when the index is clustered one.
      
      Now test_if_skip_sort_order function prefers filesort only if index isn't
      clustered.
      
      mysql-test/r/innodb_mysql.result:
        Added a test case for the bug#50843.
      mysql-test/t/innodb_mysql.test:
        Added a test case for the bug#50843.
      sql/sql_select.cc:
        Bug#50843: Filesort used instead of clustered index led to
        performance degradation.
        Now test_if_skip_sort_order function prefers filesort only if index isn't
        clustered.
      2d4db52e
  18. 29 Jan, 2010 1 commit
    • Georgi Kodinov's avatar
      Bug #49324: more valgrind errors in test_if_skip_sort_order · 6d38c898
      Georgi Kodinov authored
      Fixed 2 problems :
      1. test_if_order_by_key() was continuing on the primary key
      as if it has a primary key suffix (as the secondary keys do).
      This leads to crashes in ORDER BY <pk>,<pk>.
      Fixed by not treating the primary key as the secondary one
      and not depending on it being clustered with a primary key.
      2. The cost calculation was trying to read the records 
      per key when operating on ORDER BYs that order on all of the 
      secondary key + some of the primary key.
      This leads to crashes because of out-of-bounds array access.
      Fixed by assuming we'll find 1 record per key in such cases.
      6d38c898
  19. 15 Dec, 2009 1 commit
    • Sergey Petrunya's avatar
      Backport into MariaDB-5.2 the following: · 96e092dc
      Sergey Petrunya authored
      WL#2474 "Multi Range Read: Change the default MRR implementation to implement new MRR interface"
      WL#2475 "Batched range read functions for MyISAM/InnoDb"
              "Index condition pushdown for MyISAM/InnoDB"
      Igor's fix from sp1r-igor@olga.mysql.com-20080330055902-07614:
        There could be observed the following problems:
        1. EXPLAIN did not mention pushdown conditions from on expressions in the 
        'extra' column.  As a result if a query had no where conditions pushed 
        down to a table, but had on conditions pushed to this table the 'extra' 
        column in the EXPLAIN for the table missed 'using where'.
        2. Conditions for ref access were not eliminated from on expressions 
        though such conditions were eliminated from the where condition.
      96e092dc
  20. 01 Dec, 2009 1 commit
  21. 30 Nov, 2009 1 commit
    • Magne Mahre's avatar
      Bug #20837 Apparent change of isolation level during transaction · 732e5a26
      Magne Mahre authored
            
      SET TRANSACTION ISOLATION LEVEL is used to temporarily set
      the trans.iso.level for the next transaction.  After the
      transaction, the iso.level is (re-)set to value of the 
      session variable 'tx_isolation'.
      
      The bug is caused by setting the thd->variables.tx_isolation 
      field to the value of the session variable upon each
      statement commit.  It should only be set at the end of the
      full transaction.
      
      The fix has been to remove the setting of the variable in
      ha_autocommit_or_rollback if we're in a transaction, as it 
      will be correctly set in  either ha_rollback or 
      ha_commit_one_phase.  
      
      If, on the other hand, we're in  autocommit mode, tx_isolation 
      will be explicitly set here.
      
      
      
      mysql-test/t/innodb_mysql.test:
        "SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED" sets
        the trans.isolation for the next transaction.  We test
        that @@tx_isolation keeps this value during the transaction,
        and is only reset back to the session value at the end
        of the transaction.
      732e5a26
  22. 25 Nov, 2009 1 commit
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · 5fb71256
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 3182 [merge]
      > revision-id: ramil@mysql.com-20091018162655-z4dlolfx5s0zem8l
      > parent: alexey.kopytov@sun.com-20091016201951-fsht0wm8xn8vkzsx
      > parent: ramil@mysql.com-20091013044327-24km05wc060ied87
      > committer: Ramil Kalimullin <ramil@mysql.com>
      > branch nick: mysql-5.1-bugteam
      > timestamp: Sun 2009-10-18 21:26:55 +0500
      > message:
      >   Fix for bug#47963: Wrong results when index is used
      >   
      >   Problem: using null microsecond part in a WHERE condition 
      >   (e.g. WHERE date_time_field <= "YYYY-MM-DD HH:MM:SS.0000") 
      >   may lead to wrong results due to improper DATETIMEs 
      >   comparison in some cases.
      >   
      >   Fix: comparing DATETIMEs as strings we must trim trailing 0's
      >   in such cases.
      > ------------------------------------------------------------
      > Use --include-merges or -n0 to see merged revisions.
      5fb71256
  23. 04 Nov, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #46175: NULL read_view and consistent read assertion · 43d7fb43
      Georgi Kodinov authored
      The SE API requires mysql to notify the storage engine that
      it's going to read certain tables at the beginning of the 
      statement (by calling start_stmt(), store_lock() or
      external_lock()).
      These are typically called by the lock_tables(). 
      However SHOW CREATE TABLE is not pre-locking the tables
      because it's not expected to access the data at all.
      But for some view definitions (that include comparing a
      date/datetime/timestamp column to a string returning
      scalar subquery) the JOIN::prepare may still access data
      when materializing the scalar non-correlated subquery
      in Arg_comparator::can_compare_as_dates().
      Fixed by not materializing the subquery when the function
      is called in a SHOW/EXPLAIN/CREATE VIEW
      43d7fb43
  24. 13 Oct, 2009 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug#47963: Wrong results when index is used · 662d8367
      Ramil Kalimullin authored
      Problem: using null microsecond part (e.g. "YYYY-MM-DD HH:MM:SS.0000") 
      in a WHERE condition may lead to wrong results due to improper
      DATETIMEs comparison in some cases.
      
      Fix: as we compare DATETIMEs as strings we must trim trailing 0's
      in such cases.
      
      
      mysql-test/r/innodb_mysql.result:
        Fix for bug#47963: Wrong results when index is used
          - test result.
      mysql-test/t/innodb_mysql.test:
        Fix for bug#47963: Wrong results when index is used
          - test case.
      sql/item.cc:
        Fix for bug#47963: Wrong results when index is used
          - comparing DATETIMEs trim trailing 0's in the 
        microsecond part.
      662d8367
  25. 05 Oct, 2009 1 commit
    • John H. Embretsen's avatar
      Bug#47746 - main.innodb_mysql fails sporadically: · 85bb4aa0
      John H. Embretsen authored
      Mask part of EXPLAIN output with '#' to account for varying row count estimation.
      
      mysql-test/include/mix1.inc:
        Mask 'rows' column in EXPLAIN output (number varies sometimes between 1 and 2).
      mysql-test/r/innodb_mysql.result:
        Update result file after masking of rows estimation in EXPLAIN output.
      85bb4aa0
  26. 15 Sep, 2009 1 commit
    • unknown's avatar
      MySQL 5.1.38 after-merge fixes. · 9ec5b6f4
      unknown authored
      Fix some mistakes in the original merge found during review.
      
      mysql-test/include/concurrent.inc:
        Add missing lines mistakenly omitted in merge.
      mysql-test/include/mix1.inc:
        Revert wrong change done during merge.
      mysql-test/include/wait_for_status_var.inc.moved:
        Remove file which was accidentally not removed during conflict resolution in merge.
      mysql-test/r/innodb_mysql.result:
        Revert result file change following fixing root problem in merge.
      9ec5b6f4
  27. 09 Sep, 2009 1 commit
  28. 07 Jul, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #36259 (Optimizing with ORDER BY) and bug#45828 (Optimizer won't · 33380cf0
      Georgi Kodinov authored
      use partial primary key if another index can prevent filesort
      
      The fix for bug #28404 causes the covering ordering indexes to be 
      preferred unconditionally over non-covering and ref indexes.
      
      Fixed by comparing the cost of using a covering index to the cost of
      using a ref index even for covering ordering indexes.
      Added an assertion to clarify the condition the local variables should
      be in.
      
      mysql-test/include/mix1.inc:
        Bug #36259: fixed a non-stable test case
      mysql-test/r/innodb_mysql.result:
        Bug #36259 and #45828 : test case
      mysql-test/t/innodb_mysql.test:
        Bug #36259 and #45828 : test case
      sql/sql_select.cc:
        Bug #36259 and #45828 : don't consider covering indexes supperior to
        ref keys.
      33380cf0
  29. 24 Jun, 2009 1 commit
    • MySQL Build Team's avatar
      Backport into build-200906240007-5.1.34sp1 · f5883e8d
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 2852.12.6
      > tags: clone-5.1.35-build, mysql-5.1.35
      > revision-id: gshchepa@mysql.com-20090513075139-g50shsfjaf1dstdn
      > parent: joerg@mysql.com-20090508190407-ymqxmp6daeta6fdj
      > committer: Gleb Shchepa <gshchepa@mysql.com>
      > branch nick: mysql-5.1
      > timestamp: Wed 2009-05-13 12:51:39 +0500
      > message:
      >   Bug #44290: explain crashes for subquery with distinct in
      >               SQL_SELECT::test_quick_select
      >   
      >   The crash was caused by an incomplete cleanup of JOIN_TAB::select
      >   during the filesort of rows for GROUP BY clause inside a subquery.
      >   Queries where a quick index access is replaced with filesort was
      >   was affected. For example:
      >   
      >     SELECT 1 FROM
      >       (SELECT COUNT(DISTINCT c1) FROM t1
      >          WHERE c2 IN (1, 1) AND c3 = 2 GROUP BY c2) x
      >   
      >   Quick index access related data in the SQL_SELECT::test_quick_select
      >   function was inconsistent after an incomplete cleanup.
      >   This function has been completed to prevent crashes in the
      >   SQL_SELECT::test_quick_select function.
      f5883e8d
  30. 07 Jun, 2009 1 commit
    • Gleb Shchepa's avatar
      Bug #44886: SIGSEGV in test_if_skip_sort_order() - · ed7f0f30
      Gleb Shchepa authored
                  uninitialized variable used as subscript
      
      Grouping select from a "constant" InnoDB table (a table
      of a single row) joined with other tables caused a crash.
      
      
      mysql-test/r/innodb_mysql.result:
        Added test case for bug bug #44886.
      mysql-test/t/innodb_mysql.test:
        Added test case for bug bug #44886.
      sql/sql_select.cc:
        Bug #44886: SIGSEGV in test_if_skip_sort_order() -
                    uninitialized variable used as subscript
        
        1. The test_if_order_by_key function returned unitialized
           used_key_parts parameter in case of a "constant" InnoDB
           table. Calling function uses this parameter values as
           an array index, thus sometimes it caused a crash.
           The test_if_order_by_key function has been modified
           to set used_key_parts to 0 (no need for ordering).
        
        2. The test_if_skip_sort_order function has been
           modified to accept zero used_key_parts value and
           to prevent an array access by negative index.
      ed7f0f30
  31. 04 Jun, 2009 1 commit
  32. 25 May, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #44399 : crash with statement using TEXT columns, aggregates, GROUP BY, and · 73481404
      Georgi Kodinov authored
      HAVING
                  
      When calculating GROUP BY the server caches some expressions. It does
      that by allocating a string slot (Item_copy_string) and assigning the 
      value of the expression to it. This effectively means that the result
      type of the expression can be changed from whatever it was to a string.
      As this substitution takes place after the compile-time result type 
      calculation for IN but before the run-time type calculations, 
      it causes the type calculations in the IN function done at run time 
      to get unexpected results different from what was prepared at compile time.
                        
      In the CASE ... WHEN ... THEN ... statement there was a similar problem
      and it was solved by artificially adding a STRING argument to the set of 
      types of the IN/CASE arguments at compile time, so if any of the 
      arguments of the CASE function changes its type to a string it will 
      still be covered by the information prepared at compile time.
      
      mysql-test/include/mix1.inc:
        Bug #44399: extended the test to cover the different types
      mysql-test/r/func_in.result:
        Bug #44399: test case
      mysql-test/r/innodb_mysql.result:
        Bug #44399: extended the test to cover the different types
      mysql-test/t/func_in.test:
        Bug #44399: test case
      sql/item.cc:
        Bug #44399: Implement typed caching for GROUP BY
      sql/item.h:
        Bug #44399: Implement typed caching for GROUP BY
      sql/item_cmpfunc.cc:
        Bug #44399: remove the special case
      sql/sql_select.cc:
        Bug #44399: Implement typed caching for GROUP BY
      73481404
  33. 19 May, 2009 1 commit
    • Sergey Glukhov's avatar
      Bug#39793 Foreign keys not constructed when column has a '#' in a comment or default value · 0a892c46
      Sergey Glukhov authored
      Internal InnoDN FK parser does not recognize '\'' as quotation symbol.
      Suggested fix is to add '\'' symbol check for quotation condition
      (dict_strip_comments() function).
      
      
      innobase/dict/dict0dict.c:
        Internal InnoDN FK parser does not recognize '\'' as quotation symbol.
        Suggested fix is to add '\'' symbol check for quotation condition
        (dict_strip_comments() function).
      mysql-test/r/innodb_mysql.result:
        test result
      mysql-test/t/innodb_mysql.test:
        test case
      0a892c46
  34. 13 May, 2009 1 commit
    • Gleb Shchepa's avatar
      Bug #44290: explain crashes for subquery with distinct in · 585cf08f
      Gleb Shchepa authored
                  SQL_SELECT::test_quick_select
      
      The crash was caused by an incomplete cleanup of JOIN_TAB::select
      during the filesort of rows for GROUP BY clause inside a subquery.
      Queries where a quick index access is replaced with filesort was
      was affected. For example:
      
        SELECT 1 FROM
          (SELECT COUNT(DISTINCT c1) FROM t1
             WHERE c2 IN (1, 1) AND c3 = 2 GROUP BY c2) x
      
      Quick index access related data in the SQL_SELECT::test_quick_select
      function was inconsistent after an incomplete cleanup.
      This function has been completed to prevent crashes in the
      SQL_SELECT::test_quick_select function.
      
      
      mysql-test/include/mix1.inc:
        Add test case for bug #44290.
      mysql-test/r/innodb_mysql.result:
        Add test case for bug #44290.
      sql/sql_select.cc:
        Bug #44290: explain crashes for subquery with distinct in
                    SQL_SELECT::test_quick_select
        
        Quick index access related data in the SQL_SELECT::test_quick_select
        function was inconsistent after an incomplete cleanup.
        This function has been completed to prevent crashes in the
        SQL_SELECT::test_quick_select function.
      585cf08f
  35. 12 May, 2009 1 commit
    • Gleb Shchepa's avatar
      Bug #44290: explain crashes for subquery with distinct in · bd596287
      Gleb Shchepa authored
                  SQL_SELECT::test_quick_select
      
      The crash was caused by an incomplete cleanup of JOIN_TAB::select
      during the filesort of rows for GROUP BY clause inside a subquery.
      Queries where a quick index access is replaced with filesort was
      was affected. For example:
      
        SELECT 1 FROM
          (SELECT COUNT(DISTINCT c1) FROM t1
             WHERE c2 IN (1, 1) AND c3 = 2 GROUP BY c2) x
      
      Quick index access related data in the SQL_SELECT::test_quick_select
      function was inconsistent after an incomplete cleanup.
      This function has been completed to prevent crashes in the
      SQL_SELECT::test_quick_select function.
      
      
      mysql-test/include/mix1.inc:
        Add test case for bug #44290.
      mysql-test/r/innodb_mysql.result:
        Add test case for bug #44290.
      sql/sql_select.cc:
        Bug #44290: explain crashes for subquery with distinct in
                    SQL_SELECT::test_quick_select
        
        Quick index access related data in the SQL_SELECT::test_quick_select
        function was inconsistent after an incomplete cleanup.
        This function has been completed to prevent crashes in the
        SQL_SELECT::test_quick_select function.
      bd596287
  36. 05 May, 2009 1 commit
    • Martin Hansson's avatar
      Bug#43580: Issue with Innodb on multi-table update · 391364fa
      Martin Hansson authored
                              
      Certain multi-updates gave different results on InnoDB from
      to MyISAM, due to on-the-fly updates being used on the former and
      the update order matters.
      Fixed by turning off on-the-fly updates when update order 
      dependencies are present.
      
      
      mysql-test/r/innodb_mysql.result:
        Bug#43580: Test result.
      mysql-test/suite/rpl/r/rpl_slave_skip.result:
        Bug#43580: Changed test result. The InnoDB result is now what it would have been on MyISAM.
      mysql-test/t/innodb_mysql.test:
        Bug#43580: Test case.
      sql/sql_base.cc:
        Bug#43580: Added a word of caution about using tmp_set here.
      sql/sql_update.cc:
        Bug#43580: Fix.
        Calls to TABLE::mark_columns_needed_for_update() are moved
        from mysql_multi_update_prepare() and right before the decison
        to do on-the-fly updates to the place where we do (or don't do)
        on-the-fly updates.
      391364fa
  37. 30 Apr, 2009 1 commit
  38. 27 Mar, 2009 2 commits
    • Kristofer Pettersson's avatar
      Bug#40127 Multiple table DELETE IGNORE hangs on foreign key constraint violation · a20bc967
      Kristofer Pettersson authored
                on 5.0            
      The server crashes on an assert in net_end_statement indicating that the
      Diagnostics area wasn't set properly during execution.
      This happened on a multi table DELETE operation using the IGNORE keyword.
      The keyword is suppose to allow for execution to continue on a best effort
      despite some non-fatal errors. Instead execution stopped and no client
      response was sent which would have led to a protocol error if it hadn't been
      for the assert.
      This patch corrects this issue by checking for the existence of an IGNORE
      option before setting an error state during row-by-row delete iteration.
      
      
      mysql-test/r/innodb_mysql.result:
        * Added test case for bug40127
      mysql-test/t/innodb_mysql.test:
        * Added test case for bug40127
      sql/sql_delete.cc:
        * IGNORE option wasn't implemented in multi_delete::send_data
          and multi_delete::do_deletes
      a20bc967
    • Ramil Kalimullin's avatar
      Fix for bug #26288: savepoint not deleted, comit on empty transaction · c2c47b67
      Ramil Kalimullin authored
      Problem: commit doesn't delete savepoints if there are no changes 
      in the transaction.
      
      Fix: delete them in such cases.
      
      
      mysql-test/r/innodb_mysql.result:
        Fix for bug #26288: savepoint not deleted, comit on empty transaction
          - test result.
      mysql-test/t/innodb_mysql.test:
        Fix for bug #26288: savepoint not deleted, comit on empty transaction
          - test case.
      sql/handler.cc:
        Fix for bug #26288: savepoint not deleted, comit on empty transaction
          - call transaction.cleanup() even if nht is 0 to delete 
        possible savepoints.
      c2c47b67
  39. 20 Feb, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #42419: test suite fix · a67725ac
      Georgi Kodinov authored
      Moved the test case for the bug into a separate file (and restored the 
      original innodb_mysql test setup).
      Used the new wait_show_condition test macro to avoid the usage of sleep
      
      mysql-test/include/wait_show_condition.inc:
        Bug #42419: new test macro to wait for a row in SHOW to have a certain value.
      mysql-test/r/innodb_bug42419.result:
        Bug #42419: test case
      mysql-test/r/innodb_mysql.result:
        Bug #42419: revert to the original innodb_mysql test
      mysql-test/t/innodb_bug42419.test:
        Bug #42419: test case
      mysql-test/t/innodb_mysql-master.opt:
        Bug #42419: revert to the original innodb_mysql test
      mysql-test/t/innodb_mysql.test:
        Bug #42419: revert to the original innodb_mysql test
      a67725ac