An error occurred fetching the project authors.
  1. 28 Dec, 2010 1 commit
    • Kent Boortz's avatar
      - Added/updated copyright headers · fddb1f1b
      Kent Boortz authored
      - Removed files specific to compiling on OS/2
      - Removed files specific to SCO Unix packaging
      - Removed "libmysqld/copyright", text is included in documentation
      - Removed LaTeX headers for NDB Doxygen documentation
      - Removed obsolete NDB files
      - Removed "mkisofs" binaries
      - Removed the "cvs2cl.pl" script
      - Changed a few GPL texts to use "program" instead of "library"
      fddb1f1b
  2. 30 Jul, 2010 1 commit
    • Georgi Kodinov's avatar
      Bug #55188: GROUP BY, GROUP_CONCAT and TEXT - inconsistent results · d765e30a
      Georgi Kodinov authored
      In order to be able to check if the set of the grouping fields in a 
      GROUP BY has changed (and thus to start a new group) the optimizer
      caches the current values of these fields in a set of Cached_item 
      derived objects.
      The Cached_item_str, used for caching varchar and TEXT columns,
      is limited in length by the max_sort_length variable.
      A String buffer to store the value with an alloced length of either
      the max length of the string or the value of max_sort_length 
      (whichever is smaller) in Cached_item_str's constructor.
      Then, at compare time the value of the string to compare to was 
      truncated to the alloced length of the string buffer inside 
      Cached_item_str.
      This is all fine and valid, but only if you're not assigning 
      values near or equal to the alloced length of this buffer.
      Because when assigning values like this the alloced length is 
      rounded up and as a result the next set of data will not match the
      group buffer, thus leading to wrong results because of the changed
      alloced_length.
      Fixed by preserving the original maximum length in the 
      Cached_item_str's constructor and using this instead of the 
      alloced_length to limit the string to compare to.
      Test case added.
      d765e30a
  3. 11 May, 2010 1 commit
    • Martin Hansson's avatar
      Bug#48157: crash in Item_field::used_tables · 27ac666f
      Martin Hansson authored
            
      MySQL handles the join syntax "JOIN ... USING( field1,
      ... )" and natural joins by building the same parse tree as
      a corresponding join with an "ON t1.field1 = t2.field1 ..."
      expression would produce. This parse tree was not cleaned up
      properly in the following scenario. If a thread tries to
      lock some tables and finds that the tables were dropped and
      re-created while waiting for the lock, it cleans up column
      references in the statement by means a per-statement free
      list. But if the statement was part of a stored procedure,
      column references on the stored procedure's free list
      weren't cleaned up and thus contained pointers to freed
      objects.
            
      Fixed by adding a call to clean up the current prepared
      statement's free list.
      
      This is a backport from MySQL 5.1
      27ac666f
  4. 05 May, 2010 1 commit
    • Georgi Kodinov's avatar
      On behalf of Kristofer : · 1132c354
      Georgi Kodinov authored
      Bug#53417 my_getwd() makes assumptions on the buffer sizes which not always hold true
            
      The mysys library contains many functions for rewriting file paths. Most of these
      functions makes implicit assumptions on the buffer sizes they write to. If a path is put
      in my_realpath() it will propagate to my_getwd() which assumes that the buffer holding
      the path name is greater than 2. This is not true in cases.
            
      In the special case where a VARBIN_ITEM is passed as argument to the LOAD_FILE function
      this can lead to a crash.
            
      This patch fixes the issue by introduce more safe guards agaist buffer overruns.
      1132c354
  5. 16 Mar, 2010 1 commit
    • Martin Hansson's avatar
      Bug#50918: Date columns treated differently in Views than in · f8a1823a
      Martin Hansson authored
      Base Tables
      
      The type inferrence of a view column caused the result to be
      interpreted as the wrong type: DATE colums were interpreted
      as TIME and TIME as DATETIME. This happened because view
      columns are represented by Item_ref objects as opposed to
      Item_field's. Item_ref had no method for retrieving a TIME
      value and thus was forced to depend on the default
      implementation for any expression, which caused the
      expression to be evaluated as a string and then parsed into
      a TIME/DATETIME value.
      
      Fixed by letting Item_ref classes forward the request for a
      TIME value to the referred Item - which is a field in this
      case - this reads the TIME value directly without
      conversion.
      f8a1823a
  6. 14 Mar, 2010 1 commit
    • Staale Smedseng's avatar
      Bug #49829 Many "hides virtual function" warnings with · 3f4d8edb
      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.
      3f4d8edb
  7. 12 Mar, 2010 1 commit
  8. 06 Feb, 2010 1 commit
    • Gleb Shchepa's avatar
      Bug #45640: optimizer bug produces wrong results · 57e5f848
      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.
      57e5f848
  9. 12 Jan, 2010 1 commit
    • Martin Hansson's avatar
      Bug#48157: crash in Item_field::used_tables · e57ea46d
      Martin Hansson authored
      MySQL handles the join syntax "JOIN ... USING( field1,
      ... )" and natural joins by building the same parse tree as
      a corresponding join with an "ON t1.field1 = t2.field1 ..."
      expression would produce. This parse tree was not cleaned up
      properly in the following scenario. If a thread tries to
      lock some tables and finds that the tables were dropped and
      re-created while waiting for the lock, it cleans up column
      references in the statement by means a per-statement free
      list. But if the statement was part of a stored procedure,
      column references on the stored procedure's free list weren't
      cleaned up and thus contained pointers to freed objects.
      
      Fixed by adding a call to clean up the current prepared
      statement's free list.
      e57ea46d
  10. 22 Dec, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #49734: Crash on EXPLAIN EXTENDED UNION ... ORDER BY <any non-const-function> · ef22a7bf
      Georgi Kodinov authored
      Several problems fixed : 
      1. Non constant expressions in UNION ... ORDER BY were not correctly cleaned up
      in st_select_lex_unit::cleanup() causing crashes in EXPLAIN EXTENDED because of
      fields quoted by these expressions pointing to the already freed temporary table
      used to calculate the UNION.
      Fixed by correctly cleaning up expressions of any depth.
      
      2. Subqueries in the order by part of UNION ... ORDER BY ... caused a crash in 
      EXPLAIN EXTENDED because of a transformation attempt made during EXPLAIN EXTENDED
      execution. Fixed by not doing the transformation when in EXPLAIN.
      
      3. Fulltext functions caused crash when in the ORDER BY part of an un-parenthesized
      UNION that gets "promoted" to be valid for the whole union, e.g. 
      SELECT * FROM t1 UNION SELECT * FROM t2 ORDER BY MATCHES (a) AGAINST ('abc' IN BOOLEAN MODE).
      This is a case that demonstrates a more general problem of parts of the query being
      moved to another level. When doing such transformation late in the optimization run
      when most of the flags about the contents of the query are already aggregated it's possible 
      to "split" the flags so that they correctly reflect the new queries after the transformation.
      In specific the ST_SELECT_LEX::ftfunc_list is holding all the free text function for all the 
      parts of the second SELECT in the UNION and we don't know what part of that is in the ORDER BY
      that we're to move to the UNION level and what part is about the other parts of the second SELECT.
      Fixed by throwing and error when such statements are about to be processed by adding a check 
      for the presence of MATCH() inside the ORDER BY clause that's going to get promoted to UNION.
      To workaround this new limitation one must parenthesize the UNION SELECTs and provide a real 
      global ORDER BY for the UNION outside of the parenthesis.
      ef22a7bf
  11. 13 Dec, 2009 1 commit
    • Alexey Kopytov's avatar
      Bug #42849: innodb crash with varying time_zone on partitioned · a8cfe3d4
      Alexey Kopytov authored
                  timestamp primary key 
       
      Since TIMESTAMP values are adjusted by the current time zone  
      settings in both numeric and string contexts, using any 
      expressions involving TIMESTAMP values as a  
      (sub)partitioning function leads to undeterministic behavior of  
      partitioned tables. The effect may vary depending on a storage  
      engine, it can be either incorrect data being retrieved or  
      stored, or an assertion failure. The root cause of this is the  
      fact that the calculated partition ID may differ from a  
      previously calculated ID for the same data due to timezone  
      adjustments of the partitioning expression value. 
       
      Fixed by disabling any expressions involving TIMESTAMP values  
      to be used in partitioning functions with the follwing two 
      exceptions: 
       
      1. Creating or altering into a partitioned table that violates 
      the above rule is not allowed, but opening existing such tables 
      results in a warning rather than an error so that such tables 
      could be fixed. 
       
      2. UNIX_TIMESTAMP() is the only way to get a 
      timezone-independent value from a TIMESTAMP column, because it 
      returns the internal representation (a time_t value) of a 
      TIMESTAMP argument verbatim. So UNIX_TIMESTAMP(timestamp_column)
      is allowed and should be used to fix existing tables if one 
      wants to use TIMESTAMP columns with partitioning.
      a8cfe3d4
  12. 25 Nov, 2009 2 commits
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · b84555ef
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 3148.9.6
      > revision-id: martin.hansson@sun.com-20091102122407-krzh4h0i052lbwr5
      > parent: davi.arnaut@sun.com-20091102112236-k3myix2xy8miyv4s
      > committer: Martin Hansson <martin.hansson@sun.com>
      > branch nick: 5.1bt
      > timestamp: Mon 2009-11-02 13:24:07 +0100
      > message:
      >   Bug#47925: regression of range optimizer and date comparison in 5.1.39!
      >   
      >   When a query was using a DATE or DATETIME value formatted
      >   using any other separator characters beside hyphen '-', a
      >   query with a greater-or-equal '>=' condition matching only
      >   the greatest value in an indexed column, the result was
      >   empty if index range scan was employed.
      >   
      >   The range optimizer got a new feature between 5.1.38 and
      >   5.1.39 that changes a greater-or-equal condition to a
      >   greater-than if the value matching that in the query was not
      >   present in the table. But the value comparison function
      >   compared the dates as strings instead of dates.
      >   
      >   The bug was fixed by splitting the function
      >   get_date_from_str in two: One part that parses and does
      >   error checking. This function is now visible outside the
      >   module. The old get_date_from_str now calls the new
      >   function.
      b84555ef
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · c084d701
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 3148.8.5
      > revision-id: davi.arnaut@sun.com-20091102112139-pztthzy6qj8jzomn
      > parent: svoj@sun.com-20091103091902-vwszwwpfi1f4zrpn
      > committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
      > branch nick: 48370-5.1
      > timestamp: Mon 2009-11-02 09:21:39 -0200
      > message:
      >   Bug#48370: Absolutely wrong calculations with GROUP BY and decimal fields when using IF
      >   Bug#45261: Crash, stored procedure + decimal
      >   
      >   Revert fix for Bug#45261 due to unforeseen bugs.
      c084d701
  13. 17 Nov, 2009 1 commit
    • Evgeny Potemkin's avatar
      Bug#43668: Wrong comparison and MIN/MAX for YEAR(2) · 726e8390
      Evgeny Potemkin authored
      MySQL manual describes values of the YEAR(2) field type as follows:
      values 00 - 69 mean 2000 - 2069 years and values 70 - 99 mean 1970 - 1999
      years. MIN/MAX and comparison functions was comparing them as int values
      thus producing wrong result.
      
      Now the Arg_comparator class is extended with compare_year function which
      performs correct comparison of the YEAR type.
      The Item_sum_hybrid class now uses Item_cache and Arg_comparator objects to
      correctly calculate its value.
      To allow Arg_comparator to use func_name() function for Item_func and Item_sum
      objects the func_name declaration is moved to the Item_result_field class.
      A helper function is_owner_equal_func is added to the Arg_comparator class.
      It checks whether the Arg_comparator object owner is the <=> function or not.
      A helper function setup is added to the Item_sum_hybrid class. It sets up
      cache item and comparator.
      726e8390
  14. 06 Nov, 2009 1 commit
    • Evgeny Potemkin's avatar
      Bug#34384: Slow down on constant conversion. · 60d358af
      Evgeny Potemkin authored
      When values of different types are compared they're converted to a type that
      allows correct comparison. This conversion is done for each comparison and
      takes some time. When a constant is being compared it's possible to cache the
      value after conversion to speedup comparison. In some cases (large dataset,
      complex WHERE condition with many type conversions) query might be executed
      7% faster.
      
      A test case isn't provided because all changes are internal and isn't visible
      outside.
      
      The behavior of the Item_cache is changed to cache values on the first request
      of cached value rather than at the moment of storing item to be cached.
      A flag named value_cached is added to the Item_cache class. It's set to TRUE
      when cache holds the value of the last stored item.
      Function named cache_value() is added to the Item_cache class and derived classes.
      This function actually caches the value of the saved item.
      Item_cache_xxx::store functions now only store item to be cached and set
      value_cached flag to FALSE.
      Item_cache_xxx::val_xxx functions are changed to call cache_value function
      prior to returning cached value if value_cached is FALSE.
      The Arg_comparator::set_cmp_func function now calls cache_converted_constant
      to cache constants if they need a type conversion.
      The Item_cache::get_cache function is overloaded to allow setting of the
      cache type.
      The cache_converted_constant function is added to the Arg_comparator class.
      It checks whether a value can and should be cached and if so caches it.
      60d358af
  15. 02 Nov, 2009 2 commits
    • Martin Hansson's avatar
      Bug#47925: regression of range optimizer and date comparison in 5.1.39! · f539e0c8
      Martin Hansson authored
      When a query was using a DATE or DATETIME value formatted
      using any other separator characters beside hyphen '-', a
      query with a greater-or-equal '>=' condition matching only
      the greatest value in an indexed column, the result was
      empty if index range scan was employed.
      
      The range optimizer got a new feature between 5.1.38 and
      5.1.39 that changes a greater-or-equal condition to a
      greater-than if the value matching that in the query was not
      present in the table. But the value comparison function
      compared the dates as strings instead of dates.
      
      The bug was fixed by splitting the function
      get_date_from_str in two: One part that parses and does
      error checking. This function is now visible outside the
      module. The old get_date_from_str now calls the new
      function.
      f539e0c8
    • Davi Arnaut's avatar
      Bug#48370: Absolutely wrong calculations with GROUP BY and decimal fields when using IF · 9a083628
      Davi Arnaut authored
      Bug#45261: Crash, stored procedure + decimal
      
      Revert fix for Bug#45261 due to unforeseen bugs.
      9a083628
  16. 26 Aug, 2009 2 commits
    • Mattias Jonsson's avatar
      Bug#20577: Partitions: use of to_days() function leads to selection failures · 401fb7c6
      Mattias Jonsson authored
      Problem was that the partition containing NULL values
      was pruned away, since '2001-01-01' < '2001-02-00' but
      TO_DAYS('2001-02-00') is NULL.
      
      Added the NULL partition for RANGE/LIST partitioning on TO_DAYS()
      function to be scanned too.
      
      Also fixed a bug that added ALLOW_INVALID_DATES to sql_mode
      (SELECT * FROM t WHERE date_col < '1999-99-99' on a RANGE/LIST
      partitioned table would add it).
      401fb7c6
    • Mattias Jonsson's avatar
      Bug#46362: Endpoint should be set to false for TO_DAYS(DATE) · 3b756a01
      Mattias Jonsson authored
      There were a problem since pruning uses the field
      for comparison (while evaluate_join_record uses longlong),
      resulting in pruning failures when comparing DATE to DATETIME.
      
      Fix was to always comparing DATE vs DATETIME as DATETIME,
      by adding ' 00:00:00' to the DATE string.
      
      And adding optimization for comparing with 23:59:59, so that
      DATETIME_col > '2001-02-03 23:59:59' ->
      TO_DAYS(DATETIME_col) > TO_DAYS('2001-02-03 23:59:59') instead
      of '>='.
      3b756a01
  17. 24 Aug, 2009 1 commit
    • Davi Arnaut's avatar
      Bug#45261: Crash, stored procedure + decimal · 31afccc4
      Davi Arnaut authored
      The problem was that creating a DECIMAL column from a decimal
      value could lead to a failed assertion as decimal values can
      have a higher precision than those attached to a table. The
      assert could be triggered by creating a table from a decimal
      with a large (> 30) scale. Also, there was a problem in
      calculating the number of digits in the integral and fractional
      parts if both exceeded the maximum number of digits permitted
      by the new decimal type.
      
      The solution is to ensure that truncation procedure is executed
      when deducing a DECIMAL column from a decimal value of higher
      precision. If the integer part is equal to or bigger than the
      maximum precision for the DECIMAL type (65), the integer part
      is truncated to fit and the fractional becomes zero. Otherwise,
      the fractional part is truncated to fit into the space left
      after the integer part is copied.
      
      This patch borrows code and ideas from Martin Hansson's patch.
      31afccc4
  18. 25 May, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #44399 : crash with statement using TEXT columns, aggregates, GROUP BY, and · 8fb82e3f
      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.
      8fb82e3f
  19. 01 Apr, 2009 1 commit
    • Gleb Shchepa's avatar
      Backport bug #37348 fix 5.1 --> 5.0. · 32360968
      Gleb Shchepa authored
      Original commentary:
      
      Bug #37348: Crash in or immediately after JOIN::make_sum_func_list
                  
      The optimizer pulls up aggregate functions which should be aggregated in
      an outer select. At some point it may substitute such a function for a field
      in the temporary table. The setup_copy_fields function doesn't take this
      into account and may overrun the copy_field buffer.
                  
      Fixed by filtering out the fields referenced through the specialized
      reference for aggregates (Item_aggregate_ref).
      Added an assertion to make sure bugs that cause similar discrepancy 
      don't go undetected.
      32360968
  20. 19 Feb, 2009 1 commit
    • Sergey Glukhov's avatar
      Bug#37601 Cast Is Not Done On Row Comparison · 6a9de01a
      Sergey Glukhov authored
      In case of ROW item each compared pair does not
      check if argumet collations can be aggregated and
      thus appropiriate item conversion does not happen.
      The fix is to add the check and convertion for ROW
      pairs.
      6a9de01a
  21. 10 Nov, 2008 1 commit
  22. 23 Oct, 2008 1 commit
  23. 17 Oct, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug #38637: COUNT DISTINCT prevents NULL testing in HAVING clause · f1a1e89f
      Georgi Kodinov authored
      IS NULL was not checking the correct row in a HAVING context.
      At the first row of a new group (where the HAVING clause is evaluated)
      the column and SELECT list references in the HAVING clause should 
      refer to the last row of the previous group and not to the current one. 
      This was not done for IS NULL, because it was using Item::is_null() doesn't
      have a  Item_is_null_result() counterpart to access the data from the 
      last row of the previous group. Note that all the Item::val_xxx() functions 
      (e.g. Item::val_int()) have their _result counterparts (e.g. Item::val_int_result()).
      
      Fixed by implementing a is_null_result() (similarly to int_result()) and
      calling this instead of is_null() column and SELECT list references inside
      the HAVING clause.
      f1a1e89f
  24. 08 Oct, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug #32124: crash if prepared statements refer to variables in the where clause · 489ad44a
      Georgi Kodinov authored
                        
      The code to get read the value of a system variable was extracting its value 
      on PREPARE stage and was substituting the value (as a constant) into the parse tree.
      Note that this must be a reversible transformation, i.e. it must be reversed before
      each re-execution.
      Unfortunately this cannot be reliably done using the current code, because there are
      other non-reversible source tree transformations that can interfere with this
      reversible transformation.
      Fixed by not resolving the value at PREPARE, but at EXECUTE (as the rest of the 
      functions operate). Added a cache of the value (so that it's constant throughout
      the execution of the query). Note that the cache also caches NULL values.
      Updated an obsolete related test suite (variables-big) and the code to test the 
      result type of system variables (as per bug 74).
      489ad44a
  25. 02 Oct, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug #37348: Crash in or immediately after JOIN::make_sum_func_list · 452fed70
      Georgi Kodinov authored
            
      The optimizer pulls up aggregate functions which should be aggregated in
      an outer select. At some point it may substitute such a function for a field
      in the temporary table. The setup_copy_fields function doesn't take this
      into account and may overrun the copy_field buffer.
            
      Fixed by filtering out the fields referenced through the specialized
      reference for aggregates (Item_aggregate_ref).
      Added an assertion to make sure bugs that cause similar discrepancy 
      don't go undetected.
      452fed70
  26. 15 Aug, 2008 1 commit
  27. 11 Aug, 2008 1 commit
    • Marc Alff's avatar
      Bug#38296 (low memory crash with many conditions in a query) · 394691cd
      Marc Alff authored
      This fix is for 5.0 only : back porting the 6.0 patch manually
      
      The parser code in sql/sql_yacc.yy needs to be more robust to out of
      memory conditions, so that when parsing a query fails due to OOM,
      the thread gracefully returns an error.
      
      Before this fix, a new/alloc returning NULL could:
      - cause a crash, if dereferencing the NULL pointer,
      - produce a corrupted parsed tree, containing NULL nodes,
      - alter the semantic of a query, by silently dropping token values or nodes
      
      With this fix:
      - C++ constructors are *not* executed with a NULL "this" pointer
      when operator new fails.
      This is achieved by declaring "operator new" with a "throw ()" clause,
      so that a failed new gracefully returns NULL on OOM conditions.
      
      - calls to new/alloc are tested for a NULL result,
      
      - The thread diagnostic area is set to an error status when OOM occurs.
      This ensures that a request failing in the server properly returns an
      ER_OUT_OF_RESOURCES error to the client.
      
      - OOM conditions cause the parser to stop immediately (MYSQL_YYABORT).
      This prevents causing further crashes when using a partially built parsed
      tree in further rules in the parser.
      
      No test scripts are provided, since automating OOM failures is not
      instrumented in the server.
      Tested under the debugger, to verify that an error in alloc_root cause the
      thread to returns gracefully all the way to the client application, with
      an ER_OUT_OF_RESOURCES error.
      394691cd
  28. 08 Apr, 2008 1 commit
    • kostja@dipika.(none)'s avatar
      Tentative implementation of · d1f93762
      kostja@dipika.(none) authored
      WL#4165 Prepared statements: validation 
      WL#4166 Prepared statements: automatic re-prepare
      Fixes
      Bug#27430 Crash in subquery code when in PS and table DDL changed after PREPARE
      Bug#27690 Re-execution of prepared statement after table was replaced with a view crashes
      Bug#27420 A combination of PS and view operations cause error + assertion on shutdown
      
      The basic idea of the patch is to keep track of table metadata between
      prepared statement prepare and execute. If some table used in the statement
      has changed, the prepared statement is re-prepared before execution.
      
      See WL#4165 and WL#4166 contents and comments in the code for details
      of the implementation.
      d1f93762
  29. 28 Feb, 2008 3 commits
    • gshchepa/uchum@host.loc's avatar
      Fixed bug #34620: item_row.cc:50: Item_row::illegal_method_call(const char*): · c5110674
      gshchepa/uchum@host.loc authored
                        Assertion `0' failed
      
      If ROW item is a part of an expression that also has
      aggregate function calls (COUNT/SUM/AVG...), a
      "splitting" with an Item::split_sum_func2 function
      is applied to that ROW item.
      Current implementation of Item::split_sum_func2
      replaces this Item_row with a newly created
      Item_aggregate_ref reference to it.
      Then the row cache tries to work with the
      Item_aggregate_ref object as with the Item_row object:
      row cache calls row-emulation methods such as cols and
      element_index. Item_aggregate_ref (like it's parent
      Item_ref) inherits dummy implementations of those
      methods from the hierarchy root Item, and call to
      them leads to failed assertions and wrong data
      output.
      
      Row-emulation virtual functions (cols, element_index, addr,
      check_cols, null_inside and bring_value) of Item_ref have
      been overloaded to forward calls to an underlying item
      reference.
      
      c5110674
    • davi@mysql.com/endora.local's avatar
      Bug#33851 Passing UNSIGNED param to EXECUTE returns ERROR 1210 · 361262c7
      davi@mysql.com/endora.local authored
      The problem is that passing anything other than a integer to a limit
      clause in a prepared statement would fail. This limitation was introduced
      to avoid replication problems (e.g: replicating the statement with a
      string argument would cause a parse failure in the slave).
      
      The solution is to convert arguments to the limit clause to a integer
      value and use this converted value when persisting the query to the log.
      361262c7
    • tnurnberg@mysql.com/white.intern.koehntopp.de's avatar
      Bug#34749: Server crash when using NAME_CONST() with an aggregate function · c6b4d7a7
      NAME_CONST('whatever', -1) * MAX(whatever) bombed since -1 was
      not seen as constant, but as FUNCTION_UNARY_MINUS(constant)
      while we are at the same time pretending it was a basic const
      item. This confused the aggregate handlers in exciting ways.
      We now make NAME_CONST() behave more consistently.
      c6b4d7a7
  30. 22 Feb, 2008 2 commits
    • anozdrin/alik@quad.'s avatar
      Fix for Bug#30217: Views: changes in metadata behaviour · 340906f4
      anozdrin/alik@quad. authored
      between 5.0 and 5.1.
        
      The problem was that in the patch for Bug#11986 it was decided
      to store original query in UTF8 encoding for the INFORMATION_SCHEMA.
      This approach however turned out to be quite difficult to implement
      properly. The main problem is to preserve the same IS-output after
      dump/restore.
        
      So, the fix is to rollback to the previous functionality, but also
      to fix it to support multi-character-set-queries properly. The idea
      is to generate INFORMATION_SCHEMA-query from the item-tree after
      parsing view declaration. The IS-query should:
        - be completely in UTF8;
        - not contain character set introducers.
        
      For more information, see WL4052.
      340906f4
    • davi@buzz.(none)'s avatar
      Post-merge fixes for bug 32890 · 23672778
      davi@buzz.(none) authored
      23672778
  31. 21 Feb, 2008 1 commit
    • davi@mysql.com/endora.local's avatar
      Bug#32890 Crash after repeated create and drop of tables and views · 0e914618
      davi@mysql.com/endora.local authored
      The problem is that CREATE VIEW statements inside prepared statements
      weren't being expanded during the prepare phase, which leads to objects
      not being allocated in the appropriate memory arenas.
      
      The solution is to perform the validation of CREATE VIEW statements
      during the prepare phase of a prepared statement. The validation
      during the prepare phase assures that transformations of the parsed
      tree will use the permanent arena of the prepared statement.
      0e914618
  32. 12 Feb, 2008 1 commit
    • anozdrin/alik@quad.'s avatar
      Fix for Bug#32538: View definition picks up character set, · d36d243d
      anozdrin/alik@quad. authored
      but not collation.
      
      The problem here was that text literals in a view were always
      dumped with character set introducer. That lead to loosing
      collation information.
      
      The fix is to dump character set introducer only if it was
      in the original query. That is now possible because there 
      is no problem any more of loss of character set of string
      literals in views -- after WL#4052 the view is dumped 
      in the original character set.
      d36d243d
  33. 27 Jan, 2008 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #33833. · 5e14047e
      igor@olga.mysql.com authored
      Two disjuncts containing equalities of the form key=const1 and key=const2 can
      be merged into one if const1 is equal to const2. To check it the common 
      collation of the constants were used rather than the collation of the field key.
      For example when the default collation of the constants was cases insensitive
      while the collation of the field was case sensitive, then two or-ed equality 
      predicates key='b' and key='B' incorrectly were merged into one f='b'. As a 
      result ref access was used instead of range access and wrong result sets were 
      returned in many cases. 
      Fixed the problem by comparing constant in the or-ed predicate with collation of
      the key field.
      5e14047e
  34. 27 Nov, 2007 1 commit