An error occurred fetching the project authors.
  1. 26 Nov, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #32036: EXISTS within a WHERE clause with a UNION · 55afc5c2
      gkodinov/kgeorge@magare.gmz authored
        crashes MySQL 5.122
      There was a difference in how UNIONs are handled
      on top level and when in sub-query.
      Because the rules for sub-queries were syntactically
      allowing cases that are not currently supported by
      the server we had crashes (this bug) or wrong results
      (bug 32051).
      Fixed by making the syntax rules for UNIONs match the 
      ones at top level.
      
      These rules however do not support nesting UNIONs, e.g.
      (SELECT a FROM t1 UNION ALL SELECT b FROM t2) 
       UNION
      (SELECT c FROM t3 UNION ALL SELECT d FROM t4)
      Supports for statements with nested UNIONs will be
      added in a future version.
      55afc5c2
  2. 22 Nov, 2007 1 commit
    • evgen@moonbone.local's avatar
      opt_range.cc: · 3f163915
      evgen@moonbone.local authored
        Fix for the bug#31048 for 64bit platforms.
      subselect.test, subselect.result:
        Corrected text case for the bug#31048.
      3f163915
  3. 21 Nov, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #30788: Inconsistent retrieval of char/varchar · 2e2ac428
      gkodinov/kgeorge@magare.gmz authored
      Index lookup does not always guarantee that we can
      simply remove the relevant conditions from the WHERE
      clause. Reasons can be e.g. conversion errors, 
      partial indexes etc. 
      The optimizer was removing these parts of the WHERE 
      condition without any further checking.
      This leads to "false positives" when using indexes.
      Fixed by checking the index reference conditions
      (using WHERE) when using indexes with sub-queries.
      2e2ac428
  4. 20 Nov, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #32400: Complex SELECT query returns correct result · 846cbf3c
      gkodinov/kgeorge@magare.gmz authored
       only on some occasions
      
      Referencing an element from the SELECT list in a WHERE 
      clause is not permitted. The namespace of the WHERE
      clause is the table columns only. This was not enforced
      correctly when resolving outer references in sub-queries.
      
      Fixed by not allowing references to aliases in a 
      sub-query in WHERE.
      846cbf3c
  5. 19 Nov, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#31048: Many nested subqueries may cause server crash. · 67cae0d4
      evgen@moonbone.local authored
      This bug is actually two. The first one manifests itself on an EXPLAIN
      SELECT query with nested subqueries that employs the filesort algorithm.
      The whole SELECT under explain is marked as UNCACHEABLE_EXPLAIN to preserve
      some temporary structures for explain. As a side-effect of this values of
      nested subqueries weren't cached and subqueries were re-evaluated many
      times. Each time buffer for filesort was allocated but wasn't freed because
      freeing occurs at the end of topmost SELECT. Thus all available memory was
      eaten up step by step and OOM event occur.
      The second bug manifests itself on SELECT queries with conditions where
      a subquery result is compared with a key field and the subquery itself also
      has such condition. When a long chain of such nested subqueries is present
      the stack overrun occur. This happens because at some point the range optimizer
      temporary puts the PARAM structure on the stack. Its size if about 8K and
      the stack is exhausted very fast.
      
      Now the subselect_single_select_engine::exec function allows subquery result
      caching when the UNCACHEABLE_EXPLAIN flag is set.
      Now the SQL_SELECT::test_quick_select function calls the check_stack_overrun
      function for stack checking purposes to prevent server crash.
      67cae0d4
  6. 10 Nov, 2007 1 commit
  7. 05 Nov, 2007 1 commit
  8. 30 Oct, 2007 1 commit
  9. 05 Jul, 2007 1 commit
  10. 29 Jun, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug#27333: subquery grouped for aggregate of outer · 38172240
      gkodinov/kgeorge@magare.gmz authored
      query / no aggregate of subquery
       The optimizer counts the aggregate functions that 
       appear as top level expressions (in all_fields) in 
       the current subquery. Later it makes a list of these
       that it uses to actually execute the aggregates in
       end_send_group().
       That count is used in several places as a flag whether
       there are aggregates functions.
       While collecting the above info it must not consider
       aggregates that are not aggregated in the current 
       context. It must treat them as normal expressions 
       instead. Not doing that leads to incorrect data about
       the query, e.g. running a query that actually has no
       aggregate functions as if it has some (and hence is
       expected to return only one row).
       Fixed by ignoring the aggregates that are not aggregated
       in the current context. 
       One other smaller omission discovered and fixed in the 
       process : the place of aggregation was not calculated for
       user defined functions. Fixed by calling 
       Item_sum::init_sum_func_check() and 
       Item_sum::check_sum_func() as it's done for the rest of 
       the aggregate functions.
      38172240
  11. 08 Jun, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #28811: crash for a query containing a subquery with · 2d29a57f
      igor@olga.mysql.com authored
      ORDER BY and LIMIT 1. 
      The bug was introduced by the patch for bug 21727. The patch
      erroneously skipped initialization of the array of headers
      for sorted records for non-first evaluations of the subquery.
      
      To fix the problem a new parameter has been added to the
      function make_char_array that performs the initialization.
      Now this function is called for any invocation of the 
      filesort procedure. Yet it allocates the buffer for sorted
      records only if this parameter is NULL.
      2d29a57f
  12. 06 Jun, 2007 2 commits
  13. 02 Jun, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #28728: a crash when executing EXPLAIN EXTENDED for a query · 5cbebf0a
      igor@olga.mysql.com authored
      using a derived table over a grouping subselect.
      
      This crash happens only when materialization of the derived tables 
      requires creation of auxiliary temporary table, for example when
      a grouping operation is carried out with usage of a temporary table.
      
      The crash happened because EXPLAIN EXTENDED when printing the query
      expression made an attempt to use the objects created in the mem_root
      of the temporary table which has been already freed by the moment
      when printing is called.
      
      This bug appeared after the method Item_field::print() had been 
      introduced.    
      5cbebf0a
  14. 17 May, 2007 1 commit
  15. 04 May, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #27807. · 6badb08c
      gkodinov/kgeorge@magare.gmz authored
      Non-correlated scalar subqueries may get executed
      in EXPLAIN at the optimization phase if they are
      part of a right hand sargable expression.
      If the scalar subquery uses a temp table to 
      materialize its results it will replace the 
      subquery structure from the parser with a simple
      select from the materialization table.
      As a result the EXPLAIN will crash as the 
      temporary materialization table is not to be shown
      in EXPLAIN at all.
      Fixed by preserving the original query structure
      right after calling optimize() for scalar subqueries
      with temp tables executed during EXPLAIN.
      6badb08c
  16. 26 Apr, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #27363: · bfa29e17
      gkodinov/kgeorge@magare.gmz authored
      Validity checks for nested set functions
      were not taking into account that the enclosed
      set function may be on a nest level that is
      lower than the nest level of the enclosing set
      function.
      Fixed by :
       - propagating max_sum_func_level
      up the enclosing set functions chain.
       - updating the max_sum_func_level of the 
         enclosing set function when the enclosed set
         function is aggregated above or on the same
         nest level of as the level of the enclosing 
         set function.
       - updating the max_arg_level of the enclosing
         set function on a reference that refers to
         an item above or on the same nest level
         as the level of the enclosing set function.
       - Treating both Item_field and Item_ref as possibly
         referencing items from outer nest levels.
      bfa29e17
  17. 15 Apr, 2007 2 commits
    • evgen@moonbone.local's avatar
      subselect.test, subselect.result: · 51badadd
      evgen@moonbone.local authored
        After merge fix.
      51badadd
    • evgen@moonbone.local's avatar
      Bug#27321: Wrong subquery result in a grouping select. · 3113ce63
      evgen@moonbone.local authored
      The Item_outer_ref class based on the Item_direct_ref class was always used
      to represent an outer field. But if the outer select is a grouping one and the 
      outer field isn't under an aggregate function which is aggregated in that
      outer select an Item_ref object should be used to represent such a field.
      If the outer select in which the outer field is resolved isn't grouping then
      the Item_field class should be used to represent such a field.
      This logic also should be used for an outer field resolved through its alias
      name.
      
      Now the Item_field::fix_outer_field() uses Item_outer_field objects to
      represent aliased and non-aliased outer fields for grouping outer selects
      only.
      Now the fix_inner_refs() function chooses which class to use to access outer
      field - the Item_ref or the Item_direct_ref. An object of the chosen class
      substitutes the original field in the Item_outer_ref object.
      The direct_ref and the found_in_select_list fields were added to the
      Item_outer_ref class.
      3113ce63
  18. 27 Mar, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #27348. · adc07255
      igor@olga.mysql.com authored
      If a set function with a outer reference s(outer_ref) cannot be aggregated 
      the outer query against which the reference has been resolved then MySQL
      interpretes s(outer_ref) in the same way as it would interpret s(const).
      Hovever the standard requires throwing an error in this situation.
      Added some code to support this requirement in ansi mode.
      Corrected another minor bug in Item_sum::check_sum_func.
       
      adc07255
  19. 22 Mar, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #27229: crash when a set function aggregated in outer · 8f9178e8
      igor@olga.mysql.com authored
      context was used as an argument of GROUP_CONCAT.
      Ensured correct setting of the depended_from field in references
      generated for set functions aggregated in outer selects.
      A wrong value of this field resulted in wrong maps returned by 
      used_tables() for these references.
      Made sure that a temporary table field is added for any set function
      aggregated in outer context when creation of a temporary table is 
      needed to execute the inner subquery. 
      8f9178e8
  20. 20 Mar, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #27257: queries containing subqueries with COUNT(*) · 19da4d39
      igor@olga.mysql.com authored
      aggregated in outer context returned wrong results.
      This happened only if the subquery did not contain any references
      to outer fields.
      As there were no references to outer fields the subquery erroneously
      was taken for non-correlated one.
      Now any set function aggregated in outer context makes the subquery
      correlated.
      19da4d39
  21. 12 Mar, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #26738: incomplete string values in a result set column · 06a315de
      igor@olga.mysql.com authored
      when the column is to be read from a derived table column which 
      was specified as a concatenation of string literals.
      The bug happened because the Item_string::append did not adjust the
      value of Item_string::max_length. As a result of it the temporary 
      table column  defined to store the concatenation of literals was 
      not wide enough to hold the whole value.
      06a315de
  22. 01 Mar, 2007 1 commit
  23. 26 Feb, 2007 1 commit
  24. 21 Feb, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#23800: Outer fields in correlated subqueries is used in a temporary table · 9a233742
      evgen@moonbone.local authored
      created for sorting.
      
      Any outer reference in a subquery was represented by an Item_field object.
      If the outer select employs a temporary table all such fields should be
      replaced with fields from that temporary table in order to point to the 
      actual data. This replacement wasn't done and that resulted in a wrong
      subquery evaluation and a wrong result of the whole query.
      
      Now any outer field is represented by two objects - Item_field placed in the
      outer select and Item_outer_ref in the subquery. Item_field object is
      processed as a normal field and the reference to it is saved in the
      ref_pointer_array. Thus the Item_outer_ref is always references the correct
      field. The original field is substituted for a reference in the
      Item_field::fix_outer_field() function.
      
      New function called fix_inner_refs() is added to fix fields referenced from
      inner selects and to fix references (Item_ref objects) to these fields.
      
      The new Item_outer_ref class is a descendant of the Item_direct_ref class.
      It additionally stores a reference to the original field and designed to
      behave more like a field.
      9a233742
  25. 16 Feb, 2007 1 commit
  26. 30 Jan, 2007 2 commits
    • malff/marcsql@weblab.(none)'s avatar
      manual merge · 52e614c5
      malff/marcsql@weblab.(none) authored
      52e614c5
    • malff/marcsql@weblab.(none)'s avatar
      Bug#21904 (parser problem when using IN with a double "(())") · f5ad4eed
      malff/marcsql@weblab.(none) authored
      Before this fix, a IN predicate of the form: "IN (( subselect ))", with two
      parenthesis, would be evaluated as a single row subselect: if the subselect
      returns more that 1 row, the statement would fail.
      
      The SQL:2003 standard defines a special exception in the specification,
      and mandates that this particular form of IN predicate shall be equivalent
      to "IN ( subselect )", which involves a table subquery and works with more
      than 1 row.
      
      This fix implements "IN (( subselect ))", "IN ((( subselect )))" etc
      as per the SQL:2003 requirement.
      
      All the details related to the implementation of this change have been
      commented in the code, and the relevant sections of the SQL:2003 spec
      are given for reference, so they are not repeated here.
      
      Having access to the spec is a requirement to review in depth this patch.
      f5ad4eed
  27. 26 Jan, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #24653. · 36df33d8
      igor@olga.mysql.com authored
      The bug report has demonstrated the following two problems.
      1. If an ORDER/GROUP BY list includes a constant expression being 
      optimized away and, at the same time, containing single-row
      subselects that return more that one row, no error is reported.
      Strictly speaking the standard allows to ignore error in this case.
      Yet, now a corresponding fatal error is reported in this case.
      2. If a query requires sorting by expressions containing single-row
      subselects that, however, return more than one row, then the execution
      of the query may cause a server crash. 
      To fix this some code has been added that blocks execution of a subselect
      item in case of a fatal error in the method Item_subselect::exec.
      36df33d8
  28. 19 Jan, 2007 1 commit
  29. 12 Dec, 2006 1 commit
  30. 03 Dec, 2006 1 commit
    • holyfoot/hf@mysql.com/deer.(none)'s avatar
      bug #20835 (Subqueries: literal string with =any fails) · 75b14779
      holyfoot/hf@mysql.com/deer.(none) authored
      We create Item_cache_* object for each operand for each left operand of
      a subquery predicate. We also create Item_func_conv_charset for each string
      constant that needs charset conversion. So here we have Item_cache wrapped
      into Item_func_conv_charset.
      When Item_func_conv_charset wraps an constant Item it gets it's value
      in constructor. The problem is that Item_cache is ready to be used only
      at execution time, which is too late.
      The fix makes Item_cache wrapping constant to get ready at fix_fields() time.
      75b14779
  31. 20 Nov, 2006 1 commit
    • monty@mysql.com/nosik.monty.fi's avatar
      Remove compiler warnings · e8258798
      monty@mysql.com/nosik.monty.fi authored
      (Mostly in DBUG_PRINT() and unused arguments)
      Fixed bug in query cache when used with traceing (--with-debug)
      Fixed memory leak in mysqldump
      Removed warnings from mysqltest scripts (replaced -- with #)
      e8258798
  32. 07 Nov, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #11032: getObject() returns a String for a sub-query of type datetime · cf1ca923
      gkodinov/kgeorge@macbook.gmz authored
       - When returning metadata for scalar subqueries the actual type of the
         column was calculated based on the value type, which limits the actual
         type of a scalar subselect to the set of (currently) 3 basic types : 
         integer, double precision or string. This is the reason that columns
         of types other then the basic ones (e.g. date/time) are reported as
         being of the corresponding basic type.
         Fixed by storing/returning information for the column type in addition
         to the result type.
      cf1ca923
  33. 01 Nov, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #21727. · 2a7acba7
      igor@rurik.mysql.com authored
      This is a performance issue for queries with subqueries evaluation
      of which requires filesort.
      Allocation of memory for the sort buffer at each evaluation of a
      subquery may take a significant amount of time if the buffer is rather big.
      With the fix we allocate the buffer at the first evaluation of the
      subquery and reuse it at each subsequent evaluation.
      2a7acba7
  34. 20 Oct, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #23478. · d8b6f46a
      igor@rurik.mysql.com authored
      If elements a not top-level IN subquery were accessed by an index and 
      the subquery result set included  a NULL value then the quantified
      predicate that contained the subquery was evaluated to NULL when 
      it should return a non-null value.
      d8b6f46a
  35. 17 Oct, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug#21798: memory leak during query execution with subquery in column · f7b89376
      gkodinov/kgeorge@macbook.gmz authored
                  list using a function
      When executing dependent subqueries they are re-inited and re-exec() for 
      each row of the outer context.
      The cause for the bug is that during subquery reinitialization/re-execution,
      the optimizer reallocates JOIN::join_tab, JOIN::table in make_simple_join()
      and the local variable in 'sortorder' in create_sort_index(), which is
      allocated by make_unireg_sortorder().
      Care must be taken not to allocate anything into the thread's memory pool
      while re-initializing query plan structures between subquery re-executions.
      All such items mush be cached and reused because the thread's memory pool
      is freed at the end of the whole query.
      Note that they must be cached and reused even for queries that are not 
      otherwise cacheable because otherwise it will grow the thread's memory 
      pool every time a cacheable query is re-executed. 
      We provide additional members to the JOIN structure to store references 
      to the items that need to be cached.
      f7b89376
  36. 03 Oct, 2006 1 commit
  37. 25 Sep, 2006 1 commit