An error occurred fetching the project authors.
  1. 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
  2. 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
  3. 19 Jul, 2010 1 commit
    • Jon Olav Hauglid's avatar
      Bug #54734 assert in Diagnostics_area::set_ok_status · 85e5ce0b
      Jon Olav Hauglid authored
      This assert checks that the server does not try to send OK to the
      client if there has been some error during processing. This is done
      to make sure that the error is in fact sent to the client.
      
      The problem was that view errors during processing of WHERE conditions
      in UPDATE statements where not detected by the update code. It therefore
      tried to send OK to the client, triggering the assert.
      The bug was only noticeable in debug builds.
      
      This patch fixes the problem by making sure that the update code
      checks for errors during condition processing and acts accordingly.
      85e5ce0b
  4. 09 Jul, 2010 1 commit
    • Sergey Glukhov's avatar
      Bug#54416 MAX from JOIN with HAVING returning NULL with 5.1 and Empty set · 01313636
      Sergey Glukhov authored
      The problem there is that HAVING condition evaluates const
      parts of condition despite the condition has references
      on aggregate functions. Table t1 became const tables
      after make_join_statistics and table1.pk = 1, HAVING is
      transformed into MAX(1) < 7 and taken away from HAVING.
      The fix is to skip evaluation of HAVING conts parts if
      HAVING condition has references on aggregate functions.
      
      
      mysql-test/r/having.result:
        test case
      mysql-test/t/having.test:
        test case
      sql/sql_select.cc:
        skip evaluation of HAVING conts parts if
        HAVING condition has references on aggregate functions.
      01313636
  5. 30 Jun, 2010 1 commit
    • Sergey Glukhov's avatar
      Bug#51431 Wrong sort order after import of dump file · 1c538876
      Sergey Glukhov authored
      The problem is that QUICK_SELECT_DESC behaviour depends
      on used_key_parts value which can be bigger than selected
      best_key_parts value if an engine supports clustered key.
      But used_key_parts is overwritten with best_key_parts
      value that prevents from correct selection of index
      access method. The fix is to preserve used_key_parts
      value for further use in QUICK_SELECT_DESC.
      
      
      mysql-test/r/innodb_mysql.result:
        test case
      mysql-test/t/innodb_mysql.test:
        test case
      sql/sql_select.cc:
        preserve used_key_parts value for further use in QUICK_SELECT_DESC
      1c538876
  6. 24 Jun, 2010 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug #54459: Assertion failed: param.sort_length, · 4e872863
      Ramil Kalimullin authored
      file .\filesort.cc, line 149 (part II)
      
      Problem: the server didn't disregard sort order 
      for some zero length tuples.
      
      Fix: skip sort order in such a case 
      (zero length NOT NULL string functions).
      
      
      mysql-test/r/select.result:
        Fix for bug #54459: Assertion failed: param.sort_length, 
        file .\filesort.cc, line 149 (part II)
          - test result.
      mysql-test/t/select.test:
        Fix for bug #54459: Assertion failed: param.sort_length, 
        file .\filesort.cc, line 149 (part II)
          - test case.
      sql/sql_select.cc:
        Fix for bug #54459: Assertion failed: param.sort_length, 
        file .\filesort.cc, line 149 (part II)
          - disregard sort order for zero length NOT NULL string functions
        along with zero length NOT NULL fields.
      4e872863
  7. 22 Jun, 2010 1 commit
    • MySQL Build Team's avatar
      Backport into build-201006221614-5.1.46sp1 · a0a85031
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 3351.41.1
      > revision-id: alexey.kopytov@sun.com-20100430111048-jdls6ofn4kkmpt09
      > parent: sergey.glukhov@sun.com-20100329134249-03wyhzp5k92dzhcb
      > committer: Alexey Kopytov <Alexey.Kopytov@Sun.com>
      > branch nick: my51-bug48419
      > timestamp: Fri 2010-04-30 15:10:48 +0400
      > message:
      >   Bug #48419: another explain crash..
      >   
      >   WHERE predicates containing references to empty tables in a
      >   subquery were handled incorrectly by the optimizer when
      >   executing EXPLAIN. As a result, the optimizer could try to
      >   evaluate such predicates rather than just stop with
      >   "Impossible WHERE noticed after reading const tables" as 
      >   it would do in a non-subquery case. This led to valgrind 
      >   errors and crashes.
      >   
      >   Fixed the code checking the above condition so that subqueries
      >   are not excluded and hence are handled in the same way as top
      >   level SELECTs.
      a0a85031
  8. 10 Jun, 2010 1 commit
    • Davi Arnaut's avatar
      Bug#42733: Type-punning warnings when compiling MySQL -- · 0f9ddfa9
      Davi Arnaut authored
                  strict aliasing violations.
      
      One somewhat major source of strict-aliasing violations and
      related warnings is the SQL_LIST structure. For example,
      consider its member function `link_in_list` which takes
      a pointer to pointer of type T (any type) as a pointer to
      pointer to unsigned char. Dereferencing this pointer, which
      is done to reset the next field, violates strict-aliasing
      rules and might cause problems for surrounding code that
      uses the next field of the object being added to the list.
      
      The solution is to use templates to parametrize the SQL_LIST
      structure in order to deference the pointers with compatible
      types. As a side bonus, it becomes possible to remove quite
      a few casts related to acessing data members of SQL_LIST.
      
      sql/handler.h:
        Use the appropriate template type argument.
      sql/item.cc:
        Remove now-unnecessary cast.
      sql/item_subselect.cc:
        Remove now-unnecessary casts.
      sql/item_sum.cc:
        Use the appropriate template type argument.
        Remove now-unnecessary cast.
      sql/mysql_priv.h:
        Move SQL_LIST structure to sql_list.h
        Use the appropriate template type argument.
      sql/sp.cc:
        Remove now-unnecessary casts.
      sql/sql_delete.cc:
        Use the appropriate template type argument.
        Remove now-unnecessary casts.
      sql/sql_derived.cc:
        Remove now-unnecessary casts.
      sql/sql_lex.cc:
        Remove now-unnecessary casts.
      sql/sql_lex.h:
        SQL_LIST now takes a template type argument which must
        match the type of the elements of the list. Use forward
        declaration when the type is not available, it is used
        in pointers anyway.
      sql/sql_list.h:
        Rename SQL_LIST to SQL_I_List. The template parameter is
        the type of object that is stored in the list.
      sql/sql_olap.cc:
        Remove now-unnecessary casts.
      sql/sql_parse.cc:
        Remove now-unnecessary casts.
      sql/sql_prepare.cc:
        Remove now-unnecessary casts.
      sql/sql_select.cc:
        Remove now-unnecessary casts.
      sql/sql_show.cc:
        Remove now-unnecessary casts.
      sql/sql_table.cc:
        Remove now-unnecessary casts.
      sql/sql_trigger.cc:
        Remove now-unnecessary casts.
      sql/sql_union.cc:
        Remove now-unnecessary casts.
      sql/sql_update.cc:
        Remove now-unnecessary casts.
      sql/sql_view.cc:
        Remove now-unnecessary casts.
      sql/sql_yacc.yy:
        Remove now-unnecessary casts.
      storage/myisammrg/ha_myisammrg.cc:
        Remove now-unnecessary casts.
      0f9ddfa9
  9. 27 May, 2010 1 commit
    • Sergey Glukhov's avatar
      Bug#52005 'JOIN_TAB->dependent' may be incorrectly propageted for multilevel outer joins · 8ede529b
      Sergey Glukhov authored
      There are two problems:
      1. In simplify_joins function we calculate table dependencies. If STRAIGHT_JOIN hint
      is used for whole SELECT we do not count it and as result some dependendecies
      might be lost. It leads to incorrect table order which is returned by
      join_tab_cmp_straight() function.
      2. make_join_statistics() calculate the transitive closure for relations a particular
      JOIN_TAB is 'dependent on'.
      We aggregate the dependent table_map of a JOIN_TAB by adding dependencies from other
      tables which we depend on. However, this may also cause new dependencies to be
      available after we have completed processing a certain JOIN_TAB.
      Both these problems affect condition pushdown and as result condition might be pushed
      into wrong table which leads to crash or even omitted which leads to wrong result.
      The fix:
      1. Use modified 'transitive closure' algorithm provided by Ole John Aske
      2. Update table dependences in simplify_joins according to 
         global STRAIGHT_JOIN hint.
      Note: the patch also fixes bugs 46091 & 51492
      
      
      mysql-test/r/join_outer.result:
        test case
      mysql-test/t/join_outer.test:
        test case
      sql/sql_select.cc:
        1. Use modified 'transitive closure' algorithm provided by Ole John Aske
        2. Update table dependences in simplify_joins according to 
           global STRAIGHT_JOIN hint.
      8ede529b
  10. 07 May, 2010 1 commit
  11. 06 May, 2010 1 commit
    • Martin Hansson's avatar
      Bug#52357: Assertion failed: join->best_read in · 1eada910
      Martin Hansson authored
      greedy_search optimizer_search_depth=0
      
      The algorithm inside restore_prev_nj_state failed to
      properly update the counters within the NESTED_JOIN
      tree. The counter was decremented each time a table in the
      node was removed from the QEP, the correct thing to do being
      only to decrement it when the last table in the child node
      was removed from the plan. This lead to node counters
      getting negative values and the plan thus appeared
      impossible. An assertion caught this.
      
      Fixed by not recursing up the tree unless the last table in
      the join nest node is removed from the plan
      1eada910
  12. 30 Apr, 2010 1 commit
    • Alexey Kopytov's avatar
      Bug #48419: another explain crash.. · 97374a11
      Alexey Kopytov authored
      WHERE predicates containing references to empty tables in a
      subquery were handled incorrectly by the optimizer when
      executing EXPLAIN. As a result, the optimizer could try to
      evaluate such predicates rather than just stop with
      "Impossible WHERE noticed after reading const tables" as 
      it would do in a non-subquery case. This led to valgrind 
      errors and crashes.
      
      Fixed the code checking the above condition so that subqueries
      are not excluded and hence are handled in the same way as top
      level SELECTs.
      
      mysql-test/r/explain.result:
        Added a test case for bug #48419.
      mysql-test/r/ps.result:
        Updated test results to take the new (and more correct)
        "Extra" comments in execution plans.
      mysql-test/t/explain.test:
        Added a test case for bug #48419.
      sql/sql_select.cc:
        There is no point in excluding subqueries from checking
        for identically false WHERE conditions.
      97374a11
  13. 26 Apr, 2010 1 commit
    • Alexey Kopytov's avatar
      Backport of the fix for bug #50335 to 5.0. · 6d43510a
      Alexey Kopytov authored
      The problem was in an incorrect debug assertion. The expression
      used in the failing assertion states that when finding
      references matching ORDER BY expressions, there can be only one
      reference to a single table. But that does not make any sense,
      all test cases for this bug are valid examples with multiple
      identical WHERE expressions referencing the same table which
      are also present in the ORDER BY list.
      
      Fixed by removing the failing assertion. We also have to take
      care of the 'found' counter so that we count multiple
      references only once. We rely on this fact later in
      eq_ref_table().
      
      mysql-test/r/join.result:
        Added a test case for bug #50335.
      mysql-test/t/join.test:
        Added a test case for bug #50335.
      sql/sql_select.cc:
        Removing the assertion in eq_ref_table() as it does not make
        any sense. We also have to take care of the 'found' counter so
        that we count multiple references only once. We rely on this
        fact later in eq_ref_table().
      6d43510a
  14. 15 Apr, 2010 1 commit
    • Georgi Kodinov's avatar
      Bug #52711: Segfault when doing EXPLAIN SELECT with · 93013ae6
      Georgi Kodinov authored
      union...order by (select... where...)
      
      The problem is mysql is trying to materialize and 
      cache the scalar sub-queries at JOIN::optimize
      even for EXPLAIN where the number of columns is 
      totally different from what's expected.
      Fixed by not executing the scalar subqueries 
      for EXPLAIN.
      93013ae6
  15. 05 Apr, 2010 1 commit
    • Sergey Glukhov's avatar
      Bug#52336 Segfault / crash in 5.1 copy_fields (param=0x9872980) at sql_select.cc:15355 · c1ad5072
      Sergey Glukhov authored
      The problem is that we can not use make_cond_for_table().
      This function relies on used_tables() condition
      which is not set properly for subqueries.
      As result subquery is not filtered out.
      The fix is to use remove_eq_conds() function instead
      of make_cond_for_table() func. 'remove_eq_conds()'
      algorithm relies on const_item() value and it allows
      to handle subqueries in right way.
      
      
      mysql-test/r/having.result:
        test case
      mysql-test/t/having.test:
        test case
      sql/sql_select.cc:
        The fix is to use remove_eq_conds() function instead
        of make_cond_for_table() function.
      c1ad5072
  16. 26 Mar, 2010 1 commit
    • Sergey Glukhov's avatar
      Bug#52177 crash with explain, row comparison, join, text field · f57839cd
      Sergey Glukhov authored
      The crash is the result of an attempt made by JOIN::optimize to evaluate
      the WHERE condition when no records have been actually read.
      The fix is to remove erroneous 'outer_join' variable check.
      
      
      mysql-test/r/join.result:
        test result
      mysql-test/t/join.test:
        test case
      sql/sql_select.cc:
        removed erroneous 'outer_join' variable check.
      f57839cd
  17. 24 Mar, 2010 6 commits
    • MySQL Build Team's avatar
      Backport into build-201003230706-5.1.43sp1 · f6f93eef
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 3333.1.31
      > revision-id: joro@sun.com-20091223104518-o29t0i3thgs7wgm1
      > parent: sergey.glukhov@sun.com-20100205093946-bx1hsljxlm12h7uf
      > committer: Georgi Kodinov <joro@sun.com>
      > branch nick: B39022-5.1-bugteam
      > timestamp: Wed 2009-12-23 12:45:18 +0200
      > message:
      >   Bug #39022: Mysql randomly crashing in lock_sec_rec_cons_read_sees
      >   
      >   flush_cached_records() was not correctly checking for errors after calling
      >   Item::val_xxx() methods. The expressions may contain subqueries
      >   or stored procedures that cause errors that should stop the statement.
      >   Fixed by correctly checking for errors and propagating them up the call stack.
      
      > ------------------------------------------------------------
      > revno: 3358
      > revision-id: sergey.glukhov@sun.com-20100226113925-mxwn1hfxe3l8khc4
      > parent: gshchepa@mysql.com-20100225191311-1x71dkk0h5e1alvx
      > committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
      > branch nick: mysql-5.1-bugteam
      > timestamp: Fri 2010-02-26 15:39:25 +0400
      > message:
      >   Bug#50995 Having clause on subquery result produces incorrect results.
      >   The problem is that cond->fix_fields(thd, 0) breaks
      >   condition(cuts off 'having'). The reason of that is
      >   that NULL valued Item pointer is present in the
      >   middle of Item list and it breaks the Item processing
      >   loop.
      f6f93eef
    • MySQL Build Team's avatar
      Backporting of 5.1.43sp1 release, files mysql-test/r/bug39022.result,... · 5aa2394a
      MySQL Build Team authored
      Backporting of 5.1.43sp1 release, files mysql-test/r/bug39022.result, mysql-test/t/bug39022.test added
      
      5aa2394a
    • MySQL Build Team's avatar
      Backport into build-201003230706-5.1.43sp1 · b68a8cb2
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 3333.1.11 [merge]
      > revision-id: joro@sun.com-20100201115030-hgvq6489bt0w3rty
      > parent: li-bing.song@sun.com-20100130124925-o6sfex42b6noyc6x
      > parent: joro@sun.com-20100201114016-jylx4hivgqbs0vg2
      > committer: Georgi Kodinov <joro@sun.com>
      > branch nick: test-5.1-bugteam
      > timestamp: Mon 2010-02-01 13:50:30 +0200
      > message:
      >   merge
      > ------------------------------------------------------------
      > Use --include-merges or -n0 to see merged revisions.
      b68a8cb2
    • MySQL Build Team's avatar
      Backport into build-201003230706-5.1.43sp1 · e21c3537
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 3333.1.7 [merge]
      > revision-id: ramil@mysql.com-20100129110849-1nm85j95594epnme
      > parent: joro@sun.com-20100129093628-sze9cv0neu0xbabm
      > parent: ramil@mysql.com-20100129091757-81r640na2t5bzbiz
      > committer: Ramil Kalimullin <ramil@mysql.com>
      > branch nick: mysql-5.1-bugteam
      > timestamp: Fri 2010-01-29 15:08:49 +0400
      > message:
      >   Auto-merge.
      > ------------------------------------------------------------
      > Use --include-merges or -n0 to see merged revisions.
      e21c3537
    • MySQL Build Team's avatar
      Backport into build-201003230706-5.1.43sp1 · 6c026b7e
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 3324
      > revision-id: joro@sun.com-20091223151122-ada73up1yydh0emt
      > parent: joro@sun.com-20100119124841-38vva51cuq3if7dc
      > committer: Georgi Kodinov <joro@sun.com>
      > branch nick: B49512-5.1-bugteam
      > timestamp: Wed 2009-12-23 17:11:22 +0200
      > message:
      >   Bug #49512 : subquery with aggregate function crash
      >     subselect_single_select_engine::exec()
      >   
      >   When a subquery doesn't need to be evaluated because
      >   it returns only aggregate functions and these aggregates
      >   can be calculated from the metadata about the table it
      >   was not updating all the relevant members of the JOIN 
      >   structure to reflect that this is a constant query.
      >   This caused problems to the enclosing subquery 
      >   ('<> SOME' in the test case above) trying to read some
      >   data about the tables.
      >   
      >   Fixed by setting const_tables to the number of tables 
      >   when the SELECT is optimized away.
      6c026b7e
    • Sergey Glukhov's avatar
      Bug#48483 crash in get_best_combination() · bccf219b
      Sergey Glukhov authored
      The crash happens because greedy_serach
      can not determine best plan due to
      wrong inner table dependences. These
      dependences affects join table sorting
      which performs before greedy_search starting.
      In our case table which has real 'no dependences'
      should be put on top of the list but it does not
      happen as inner tables have no dependences as well.
      The fix is to exclude RAND_TABLE_BIT mask from
      condition which checks if table dependences
      should be updated.
      
      
      mysql-test/r/join.result:
        test result
      mysql-test/t/join.test:
        test case
      sql/sql_select.cc:
        RAND_TABLE_BIT mask should not be counted as it
        prevents update of inner table dependences.
        For example it might happen if RAND() function
        is used in JOIN ON clause.
      bccf219b
  18. 19 Mar, 2010 2 commits
    • Sergey Glukhov's avatar
      Bug#51242 HAVING clause on table join produce incorrect results · ad6e00e3
      Sergey Glukhov authored
      The problem is that when we make conditon for
      grouped result const part of condition is cut off.
      It happens because some parts of 'having' condition
      which refer to outer join become const after
      make_join_statistics. These parts may be lost
      during further having condition transformation
      in JOIN::exec. The fix is adding 'having'
      condition check for const tables after
      make_join_statistics is performed.
      
      
      mysql-test/r/having.result:
        test case
      mysql-test/t/having.test:
        test result
      sql/sql_select.cc:
        added 'having' condition check for const tables
        after make_join_statistics is performed.
      ad6e00e3
    • Sergey Glukhov's avatar
      Bug#51494 crash with join, explain and 'sounds like' operator · caa1ccb0
      Sergey Glukhov authored
      The crash happens because of discrepancy between values of
      conts_tables and join->const_table_map(make_join_statisctics).
      Calculation of conts_tables used condition with
      HA_STATS_RECORDS_IS_EXACT flag check. Calculation of
      join->const_table_map does not use this flag check.
      In case of MERGE table without union with index
      the table does not become const table and
      thus join_read_const_table() is not called
      for the table. join->const_table_map supposes
      this table is const and later in make_join_select
      this table is used for making&calculation const
      condition. As table record buffer is not populated
      it leads to crash.
      The fix is adding a check if an engine supports
      HA_STATS_RECORDS_IS_EXACT flag before updating
      join->const_table_map.
      
      
      mysql-test/r/merge.result:
        test result
      mysql-test/t/merge.test:
        test case
      sql/sql_select.cc:
        adding a check if an engine supports
        HA_STATS_RECORDS_IS_EXACT flag before updating
        join->const_table_map.
      caa1ccb0
  19. 14 Mar, 2010 1 commit
    • Staale Smedseng's avatar
      Bug #49829 Many "hides virtual function" warnings with · c7fad393
      Staale Smedseng authored
      SunStudio
            
      SunStudio compilers of late warn about methods that might hide
      methods in base classes due to the use of overloading combined
      with overriding. SunStudio also warns about variables defined
      in local socpe or method arguments that have the same name as
      a member attribute of the class.
            
      This patch renames methods that might hide base class methods,
      to make it easier both for humans and compilers to see what is
      actually called. It also renames variables in local scope.
      
      
      sql/field.cc:
        Local scope variable or method argument same as class 
        attribute.
      sql/item_cmpfunc.cc:
        Local scope variable or method argument same as class 
        attribute.
      sql/item_create.cc:
        Renaming base class create() to create_func().
      sql/item_create.h:
        Renaming base class create() to create_func().
      sql/protocol.cc:
        Local scope variable or method argument same as class 
        attribute.
      sql/sql_profile.cc:
        Local scope variable or method argument same as class 
        attribute.
      sql/sql_select.cc:
        Local scope variable or method argument same as class 
        attribute.
      sql/sql_yacc.yy:
        Renaming base class create() to create_func().
      storage/federated/ha_federated.cc:
        Local scope variable or method argument same as class 
        attribute.
      storage/myisammrg/ha_myisammrg.cc:
        Local scope variable or method argument same as class 
        attribute.
      c7fad393
  20. 09 Mar, 2010 1 commit
    • Davi Arnaut's avatar
      Bug#40277: SHOW CREATE VIEW returns invalid SQL · f502deac
      Davi Arnaut authored
      The problem is that not all column names retrieved from a SELECT
      statement can be used as view column names due to length and format
      restrictions. The server failed to properly check the conformity
      of those automatically generated column names before storing the
      final view definition on disk.
      
      Since columns retrieved from a SELECT statement can be anything
      ranging from functions to constants values of any format and length,
      the solution is to rewrite to a pre-defined format any names that
      are not acceptable as a view column name.
      
      The name is rewritten to "Name_exp_%u" where %u translates to the
      position of the column. To avoid this conversion scheme, define
      explict names for the view columns via the column_list clause.
      Also, aliases are now only generated for top level statements.
      
      mysql-test/include/view_alias.inc:
        Add test case for Bug#40277
      mysql-test/r/compare.result:
        Bug#40277: SHOW CREATE VIEW returns invalid SQL
      mysql-test/r/group_by.result:
        Bug#40277: SHOW CREATE VIEW returns invalid SQL
      mysql-test/r/ps.result:
        Bug#40277: SHOW CREATE VIEW returns invalid SQL
      mysql-test/r/subselect.result:
        Bug#40277: SHOW CREATE VIEW returns invalid SQL
      mysql-test/r/subselect3.result:
        Bug#40277: SHOW CREATE VIEW returns invalid SQL
      mysql-test/r/type_datetime.result:
        Bug#40277: SHOW CREATE VIEW returns invalid SQL
      mysql-test/r/union.result:
        Bug#40277: SHOW CREATE VIEW returns invalid SQL
      mysql-test/r/view.result:
        Add test case result for Bug#40277
      mysql-test/r/view_alias.result:
        Add test case result for Bug#40277
      mysql-test/t/view_alias.test:
        Add test case for Bug#40277
      sql/sql_view.cc:
        Check if auto generated column names are conforming. Also, the
        make_unique_view_field_name function is not used as it uses the
        original name to construct a new one, which does not work if the
        name is invalid.
      f502deac
  21. 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
  22. 26 Feb, 2010 2 commits
    • Sergey Glukhov's avatar
      Bug#50995 Having clause on subquery result produces incorrect results. · 9245ed4a
      Sergey Glukhov authored
      The problem is that cond->fix_fields(thd, 0) breaks
      condition(cuts off 'having'). The reason of that is
      that NULL valued Item pointer is present in the
      middle of Item list and it breaks the Item processing
      loop.
      
      
      mysql-test/r/having.result:
        test case
      mysql-test/t/having.test:
        test case
      sql/item_cmpfunc.h:
        added ASSERT to make sure that we do not add NULL valued Item pointer
      sql/sql_select.cc:
        skip adding an item to condition if Item pointer is NULL.
        skip adding a list to condition if this list is empty.
      9245ed4a
    • 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
  23. 25 Feb, 2010 1 commit
    • Alexey Kopytov's avatar
      Bug #50335: Assertion `!(order->used & map)' in eq_ref_table · 9201bff1
      Alexey Kopytov authored
       
      The problem was in an incorrect debug assertion. The expression 
      used in the failing assertion states that when finding 
      references matching ORDER BY expressions, there can be only one 
      reference to a single table. But that does not make any sense, 
      all test cases for this bug are valid examples with multiple 
      identical WHERE expressions referencing the same table which
      are also present in the ORDER BY list. 
       
      Fixed by removing the failing assertion. We also have to take 
      care of the 'found' counter so that we count multiple 
      references only once. We rely on this fact later in 
      eq_ref_table(). 
      
      mysql-test/r/join.result:
        Added a test case for bug #50335.
      mysql-test/t/join.test:
        Added a test case for bug #50335.
      sql/sql_select.cc:
        Removing the assertion in eq_ref_table() as it does not make
        any sense. We also have to take care of the 'found' counter so 
        that we count multiple references only once. We rely on this 
        fact later in eq_ref_table().
      9201bff1
  24. 16 Feb, 2010 1 commit
    • Sergey Glukhov's avatar
      Bug#50591 bit(31) causes Duplicate entry '1-NULL' for key 'group_key' · 82e2d858
      Sergey Glukhov authored
      The problem is that during temporary table creation uneven bits
      are not taken into account for hidden fields. It leads to incorrect
      calculation&allocation of null bytes size for table record. And
      if grouped value is null we set wrong bit for this value(see end_update()).
      Fixed by adding separate calculation of uneven bit for hidden fields.
      
      
      mysql-test/r/type_bit.result:
        test case
      mysql-test/t/type_bit.test:
        test case
      sql/sql_select.cc:
        added separate calculation of uneven bit for hidden fields
      82e2d858
  25. 10 Feb, 2010 1 commit
    • Sergey Glukhov's avatar
      Bug#45195 valgrind warnings about uninitialized values in store_record_in_cache() · f2aee237
      Sergey Glukhov authored
      The problem becomes apparent only if HAVE_purify is undefined.
      It related to the part of code placed in open_table_from_share() fuction
      where we initialize record buffer only if HAVE_purify is enabled.
      So in case of HAVE_purify=OFF record buffer is not initialized
      on open table stage.
      Next we read key, find NULL value and update appropriate null bit
      but do not update record buffer. After that the record is stored
      in the join cache(store_record_in_cache). For CHAR fields we
      strip trailing spaces and in our case this procedure uses
      uninitialized record buffer.
      The fix is to skip stripping space procedure in case of null values
      for CHAR fields(partially based on 6.0 JOIN_CACHE implementation).
      
      
      mysql-test/r/join.result:
        test case
      mysql-test/t/join.test:
        test case
      sql/field.cc:
        code updated according to new CACHE_FIELD struct
      sql/sql_select.cc:
        code updated according to new CACHE_FIELD struct
      sql/sql_select.h:
        CACHE_FIELD struct:
        added new fields: Field *field, uint type;
        removed fields: Field_blob *blob_field, bool strip;
      f2aee237
  26. 09 Feb, 2010 1 commit
    • Sergey Vojtovich's avatar
      BUG#49902 - SELECT returns incorrect results · 0897669c
      Sergey Vojtovich authored
      Queries optimized with GROUP_MIN_MAX didn't cleanup KEYREAD
      optimization properly. As a result subsequent queries may
      return incomplete rows (fields are initialized to default
      values).
      
      mysql-test/r/group_min_max.result:
        A test case for BUG#49902.
      mysql-test/t/group_min_max.test:
        A test case for BUG#49902.
      sql/opt_range.cc:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      sql/opt_sum.cc:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      sql/sql_select.cc:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      sql/sql_update.cc:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      sql/table.cc:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      sql/table.h:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      0897669c
  27. 06 Feb, 2010 1 commit
    • Gleb Shchepa's avatar
      Bug #45640: optimizer bug produces wrong results · 994c0f83
      Gleb Shchepa authored
      Grouping by a subquery in a query with a distinct aggregate
      function lead to a wrong result (wrong and unordered
      grouping values).
      
      There are two related problems:
      
      1) The query like this:
      
         SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c
         FROM t1 GROUP BY aa
      
      returned wrong result, because the outer reference "t1.a"
      in the subquery was substituted with the Item_ref item.
      
      The Item_ref item obtains data from the result_field object
      that refreshes once after the end of each group. This data
      is not applicable to filesort since filesort() doesn't care
      about groups (and doesn't update result_field objects with
      copy_fields() and so on). Also that data is not applicable
      to group separation algorithm: end_send_group() checks every
      record with test_if_group_changed() that evaluates Item_ref
      items, but it refreshes those Item_ref-s only after the end
      of group, that is a vicious circle and the grouped column
      values in the output are shifted.
      
      Fix: if
             a) we grouping by a subquery and
             b) that subquery has outer references to FROM list
                of the grouping query,
           then we substitute these outer references with
           Item_direct_ref like references under aggregate
           functions: Item_direct_ref obtains data directly
           from the current record.
      
      2) The query with a non-trivial grouping expression like:
      
         SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c
         FROM t1 GROUP BY aa+0
      
      also returned wrong result, since JOIN::exec() substitutes
      references to top-level aliases in SELECT list with Item_copy
      caching items. Item_copy items have same refreshing policy
      as Item_ref items, so the whole groping expression with
      Item_copy inside returns wrong result in filesort() and
      end_send_group().
      
      Fix: include aliased items into GROUP BY item tree instead
           of Item_ref references to them.
      
      
      
      mysql-test/r/group_by.result:
        Test case for bug #45640
      mysql-test/t/group_by.test:
        Test case for bug #45640
      sql/item.cc:
        Bug #45640: optimizer bug produces wrong results
        
        Item_field::fix_fields() has been modified to resolve
        aliases in GROUP BY item trees into aliased items instead
        of Item_ref items.
      sql/item.h:
        Bug #45640: optimizer bug produces wrong results
        
        - Item::find_item_processor() has been introduced.
        - Item_ref::walk() has been modified to apply processors
          to itself too (not only to referenced item).
      sql/mysql_priv.h:
        Bug #45640: optimizer bug produces wrong results
        
        fix_inner_refs() has been modified to accept group_list
        parameter.
      sql/sql_lex.cc:
        Bug #45640: optimizer bug produces wrong results
        
        Initialization of st_select_lex::group_fix_field has
        been added.
      sql/sql_lex.h:
        Bug #45640: optimizer bug produces wrong results
        
        The st_select_lex::group_fix_field field has been introduced
        to control alias resolution in Itef_fied::fix_fields.
      sql/sql_select.cc:
        Bug #45640: optimizer bug produces wrong results
        
        - The fix_inner_refs function has been modified to treat
          subquery outer references like outer fields under aggregate
          functions, if they are included in GROUP BY item tree.
        
        - The find_order_in_list function has been modified to
          fix Item_field alias fields included in the GROUP BY item
          trees in a special manner.
      994c0f83
  28. 03 Feb, 2010 6 commits
    • MySQL Build Team's avatar
      Backport into build-201002030816-5.0.87sp1 · a800d18b
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 2818.1.26
      > revision-id: joro@sun.com-20091109140946-07wao5od7l1vn4x1
      > parent: joro@sun.com-20091110082141-ldr8p6s1joczve2j
      > committer: Georgi Kodinov <joro@sun.com>
      > branch nick: B48458-5.0-bugteam
      > timestamp: Mon 2009-11-09 16:09:46 +0200
      > message:
      >   Bug #48458: simple query tries to allocate enormous amount of
      >     memory
      >   
      >   The server was doing a bad class typecast causing setting of 
      >   wrong value for the maximum number of items in an internal
      >   structure used in equality propagation.
      >   Fixed by not doing the wrong typecast and asserting the type
      >   of the Item where it should be done.
      a800d18b
    • MySQL Build Team's avatar
      Backport into build-201002030816-5.0.87sp1 · fe1d197a
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 2818.1.19
      > revision-id: kostja@sun.com-20091103165854-7di545xruez8w207
      > parent: li-bing.song@sun.com-20091103090041-zj7nedx6ok5jgges
      > committer: Konstantin Osipov <kostja@sun.com>
      > branch nick: 5.0-41756
      > timestamp: Tue 2009-11-03 19:58:54 +0300
      > message:
      >   A fix and a test case for
      >   Bug#41756 "Strange error messages about locks from InnoDB".
      >   
      >   In JT_EQ_REF (join_read_key()) access method,
      >   don't try to unlock rows in the handler, unless certain that
      >   a) they were locked
      >   b) they are not used.
      >   
      >   Unlocking of rows is done by the logic of the nested join loop,
      >   and is unaware of the possible caching that the access method may
      >   have. This could lead to double unlocking, when a row
      >   was unlocked first after reading into the cache, and then
      >   when taken from cache, as well as to unlocking of rows which
      >   were actually used (but taken from cache).
      >   
      >   Delegate part of the unlocking logic to the access method,
      >   and in JT_EQ_REF count how many times a record was actually
      >   used in the join. Unlock it only if it's usage count is 0.
      >   
      >   Implemented review comments.
      fe1d197a
    • MySQL Build Team's avatar
      Backport into build-201002030816-5.0.87sp1 · 0286f0e9
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 2818.4.1
      > revision-id: alexey.kopytov@sun.com-20091030155453-0vlfwki805h9os62
      > parent: joerg@mysql.com-20091016122941-rf6z0keqvmlgjfto
      > committer: Alexey Kopytov <Alexey.Kopytov@Sun.com>
      > branch nick: my50-bug48131
      > timestamp: Fri 2009-10-30 18:54:53 +0300
      > message:
      >   Bug #48131: crash group by with rollup, distinct, filesort,
      >               with temporary tables
      >   
      >   There were two problems the test case from this bug was
      >   triggering:
      >   
      >   1. JOIN::rollup_init() was supposed to wrap all constant Items
      >   into another object for queries with the WITH ROLLUP modifier
      >   to ensure they are never considered as constants and therefore
      >   are written into temporary tables if the optimizer chooses to
      >   employ them for DISTINCT/GROUP BY handling.
      >   
      >   However, JOIN::rollup_init() was called before
      >   make_join_statistics(), so Items corresponding to fields in
      >   const tables could not be handled as intended, which was
      >   causing all kinds of problems later in the query execution. In
      >   particular, create_tmp_table() assumed all constant items
      >   except "hidden" ones to be removed earlier by remove_const()
      >   which led to improperly initialized Field objects for the
      >   temporary table being created. This is what was causing crashes
      >   and valgrind errors in storage engines.
      >   
      >   2. Even when the above problem had been fixed, the query from
      >   the test case produced incorrect results due to some
      >   DISTINCT/GROUP BY optimizations being performed by the
      >   optimizer that are inapplicable in the WITH ROLLUP case.
      >   
      >   Fixed by disabling inapplicable DISTINCT/GROUP BY optimizations
      >   when the WITH ROLLUP modifier is present, and splitting the
      >   const-wrapping part of JOIN::rollup_init() into a separate
      >   method which is now invoked after make_join_statistics() when
      >   the const tables are already known.
      0286f0e9
    • MySQL Build Team's avatar
      Backport into build-201002030816-5.0.87sp1 · 78103335
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 2818.1.13
      > revision-id: joro@sun.com-20091030131543-2b23fnqckgbzvete
      > parent: joro@sun.com-20091030094044-quadg0bwjy7cwqzw
      > committer: Georgi Kodinov <joro@sun.com>
      > branch nick: B48291-5.0-bugteam
      > timestamp: Fri 2009-10-30 15:15:43 +0200
      > message:
      >   Bug #48291 : crash with row() operator,select into @var, and 
      >     subquery returning multiple rows
      >   
      >   Error handling was missing when handling subqueires in WHERE 
      >   and when assigning a SELECT result to a @variable.
      >   This caused crash(es). 
      >   
      >   Fixed by adding error handling code to both the WHERE 
      >   condition evaluation and to assignment to an @variable.
      78103335
    • MySQL Build Team's avatar
      Backport into build-201002030816-5.0.87sp1 · 209a75c0
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 2818.1.12
      > revision-id: joro@sun.com-20091030094044-quadg0bwjy7cwqzw
      > parent: joro@sun.com-20091029152429-ks55fhrp4lhknyij
      > committer: Georgi Kodinov <joro@sun.com>
      > branch nick: B48293-5.0-bugteam
      > timestamp: Fri 2009-10-30 11:40:44 +0200
      > message:
      >   Bug #48293: crash with procedure analyse, view with > 10 columns,
      >   having clause...
      >   
      >   The fix for bug 46184 was not very complete. It was not covering
      >   views using temporary tables and multiple tables in a FROM clause.
      >   Fixed by reverting the fix for 46184 and making a more general
      >   check that is checking at the right execution stage and for all
      >   of the non-supported cases.
      >   Now PROCEDURE ANALYZE on non-top level SELECT is also forbidden.
      >   Updated the analyse.test and subselect.test accordingly.
      209a75c0
    • MySQL Build Team's avatar
      Backport into build-201002030816-5.0.87sp1 · 41894be0
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 2818.1.4
      > revision-id: ramil@mysql.com-20091021090408-208mvwwrcroi2j8c
      > parent: azundris@mysql.com-20091021033856-ydodp4q42o58e7ka
      > committer: Ramil Kalimullin <ramil@mysql.com>
      > branch nick: b47019-5.0-bugteam
      > timestamp: Wed 2009-10-21 14:04:08 +0500
      > message:
      >   Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
      >   line 138 when forcing a spatial index
      >   
      >   Problem: "Spatial indexes can be involved in the search 
      >   for queries that use a function such as MBRContains() 
      >   or MBRWithin() in the WHERE clause".
      >   Using spatial indexes for JOINs with =, <=> etc.
      >   predicates is incorrect.
      >   
      >   Fix: disable spatial indexes for such queries.
      41894be0