An error occurred fetching the project authors.
  1. 15 Dec, 2009 2 commits
  2. 25 Nov, 2009 2 commits
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · d8f41c85
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 1810.3961.7
      > 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.
      > ------------------------------------------------------------
      d8f41c85
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · c7f31d41
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 1810.3959.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.
      c7f31d41
  3. 13 Nov, 2009 1 commit
    • Jorgen Loland's avatar
      Bug#48052: Valgrind warning - uninitialized value in · 2a254a13
      Jorgen Loland authored
                 init_read_record() - (records.cc:274)
            
      Item_cond::used_tables_cache was accessed in
      records.cc#init_read_record() without being initialized. It had
      not been initialized because it was wrongly assumed that the
      Item's variables would not be accessed, and hence
      quick_fix_field() was used instead of fix_fields() to save a few
      CPU cycles at creation time.
      
      The fix is to properly initilize the Item by replacing
      quick_fix_field() with fix_fields().
      2a254a13
  4. 09 Nov, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #48458: simple query tries to allocate enormous amount of · 48c67b2c
      Georgi Kodinov authored
        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.
      48c67b2c
  5. 30 Oct, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #48291 : crash with row() operator,select into @var, and · a0bea5ee
      Georgi Kodinov authored
        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.
      a0bea5ee
  6. 21 Oct, 2009 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, · 256e3ec0
      Ramil Kalimullin authored
      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.
      256e3ec0
  7. 26 Jun, 2009 1 commit
    • Evgeny Potemkin's avatar
      Bug#45266: Uninitialized variable lead to an empty result. · 0e64988a
      Evgeny Potemkin authored
      The TABLE::reginfo.impossible_range is used by the optimizer to indicate
      that the condition applied to the table is impossible. It wasn't initialized
      at table opening and this might lead to an empty result on complex queries:
      a query might set the impossible_range flag on a table and when the query finishes,
      all tables are returned back to the table cache. The next query that uses the table
      with the impossible_range flag set and an index over the table will see the flag
      and thus return an empty result.
      
      The open_table function now initializes the TABLE::reginfo.impossible_range
      variable.
      0e64988a
  8. 28 Apr, 2009 1 commit
    • Gleb Shchepa's avatar
      backport from 6.0: · fa01a4ed
      Gleb Shchepa authored
      Bug #40925: Equality propagation takes non indexed attribute
      
      Query execution plans and execution time of queries like
      
        select a, b, c from t1
          where a > '2008-11-21' and b = a limit 10
      
      depended on the order of equality operator parameters:
      "b = a" and "a = b" are not same. 
      
      
      An equality propagation algorithm has been fixed:
      the substitute_for_best_equal_field function should not
      substitute a field for an equal field if both fields belong
      to the same table.
      fa01a4ed
  9. 16 Mar, 2009 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug #42957: no results from · 0a050535
      Ramil Kalimullin authored
      select where .. (col=col and col=col) or ... (false expression)
      
      Problem: optimizer didn't take into account a singular case 
      when we eliminated all the predicates at the AND level of WHERE.
      That may lead to wrong results.
      
      Fix: replace (a=a AND a=a...) with TRUE if we eliminated all the
      predicates.
      0a050535
  10. 24 Dec, 2008 1 commit
  11. 09 Dec, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug #37936: ASSERT_COLUMN_MARKED_FOR_WRITE in Field_datetime::store , · 71296ae2
      Georgi Kodinov authored
      Field_varstring::store
            
      The code that temporary saved the bitmaps of the read set and the write set so that
      it can set it to all columns for debug purposes was not expecting that the
      table->read_set and table->write_set can be the same. And was always saving both in 
      sequence.
      As a result the original value was never restored.
      Fixed by saving & restoring the original value only once if the two sets are the
      same (in a special set of functions).
      71296ae2
  12. 17 Feb, 2008 1 commit
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
      Bug #32942 now() - interval '7200' second NOT pre-calculated, causing "full table scan" · 7abba3b0
      holyfoot/hf@mysql.com/hfmain.(none) authored
      Problem is not about intervals and doesn't actually cause 'full table scan'.
      We have an optimization for DISTINCT when we have
      'DISTINCT field_from_first_join_table' we don't need to read all the
      rows from the JOIN-ed table if we found one conforming row.
      It stopped working in 5.0 as we return NESTED_LOOP_OK if we came upon
      that case in the evaluate_join_record() and that doesn't break the
      recordreading loop in sub_select().
      
      Fixed by returning NESTED_LOOP_NO_MORE_ROWS in this case.
      7abba3b0
  13. 13 Feb, 2008 1 commit
  14. 17 Nov, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #32335. · f93b5a9c
      gshchepa/uchum@gleb.loc authored
      Comparison of a BIGINT NOT NULL column with a constant arithmetic
      expression that evaluates to NULL caused error 1048: "Column '...'
      cannot be null".
      
      Made convert_constant_item() check if the constant expression is NULL
      before attempting to store it in a field. Attempts to store NULL in a
      NOT NULL field caused query errors.
      f93b5a9c
  15. 14 Nov, 2007 1 commit
  16. 10 Nov, 2007 1 commit
    • tnurnberg@mysql.com/white.intern.koehntopp.de's avatar
      Bug#31800: Date comparison fails with timezone and slashes for greater than comparison · dd7452c2
      BETWEEN was more lenient with regard to what it accepted as a DATE/DATETIME
      in comparisons than greater-than and less-than were. ChangeSet makes < >
      comparisons similarly robust with regard to trailing garbage (" GMT-1")
      and "missing" leading zeros. Now all three comparators behave similarly
      in that they throw a warning for "junk" at the end of the data, but then
      proceed anyway if possible. Before < > fell back on a string- (rather than
      date-) comparison when a warning-condition was raised in the string-to-date
      conversion. Now the fallback only happens on actual errors, while warning-
      conditions still result in a warning being to delivered to the client.
      dd7452c2
  17. 07 Nov, 2007 2 commits
    • kaa@polly.(none)'s avatar
      Fix for bug #32103: optimizer crash when join on int and mediumint with · f1a3c364
      kaa@polly.(none) authored
      variable in where clause.
      
      Problem: the new_item() method of Item_uint used an incorrect
      constructor. "new Item_uint(name, max_length)" calls
      Item_uint::Item_uint(const char *str_arg, uint length) which assumes the
      first argument to be the string representation of the value, not the
      item's name. This could result in either a server crash or incorrect
      results depending on usage scenarios.
      
      Fixed by using the correct constructor in new_item():
      Item_uint::Item_uint(const char *str_arg, longlong i, uint length).
      f1a3c364
    • kaa@polly.(none)'s avatar
      Fix for bug #30666: Incorrect order when using range conditions on 2 · 4aa04022
      kaa@polly.(none) authored
      tables or more
      
      The problem was that the optimizer used the join buffer in cases when
      the result set is ordered by filesort. This resulted in the ORDER BY
      clause being ignored, and the records being returned in the order
      determined by the order of matching records in the last table in join.
      
      Fixed by relaxing the condition in make_join_readinfo() to take
      filesort-ordered result sets into account, not only index-ordered ones.
      4aa04022
  18. 25 Oct, 2007 1 commit
  19. 23 Oct, 2007 1 commit
    • anozdrin/alik@station.'s avatar
      Patch for BUG#30736: Row Size Too Large Error Creating a Table and · b2264ff8
      anozdrin/alik@station. authored
      Inserting Data.
      
      The problem was that under some circumstances Field class was not
      properly initialized before calling create_length_to_internal_length()
      function, which led to assert failure.
      
      The fix is to do the proper initialization.
      
      The user-visible problem was that under some circumstances
      CREATE TABLE ... SELECT statement crashed the server or led
      to wrong error message (wrong results).
      b2264ff8
  20. 19 Sep, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #30639: limit offset,rowcount wraps when rowcount >= 2^32 in windows · c2abf960
      gkodinov/kgeorge@magare.gmz authored
       The parser uses ulonglong to store the LIMIT number. This number
       then is stored into a variable of type ha_rows. ha_rows is either
       4 or 8 byte depending on the BIG_TABLES define from config.h
       So an overflow may occur (and LIMIT becomes zero) while storing an
       ulonglong value in ha_rows.
       Fixed by :
        1. Using the maximum possible value for ha_rows on overflow
        2. Defining BIG_TABLES for the windows builds (to match the others) 
      c2abf960
  21. 15 Sep, 2007 1 commit
  22. 13 Sep, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #27695. · e4eadcfb
      gshchepa/uchum@gleb.loc authored
      Declaring an all space column name in the SELECT FROM DUAL or in a view
      leads to misleading warning message:
      "Leading spaces are removed from name ' '".
      
      The Item::set_name method has been modified to raise warnings like
      "Name ' ' has become ''" in case of the truncation of an all
      space identifier to an empty string identifier instead of the
      "Leading spaces are removed from name ' '" warning message.
      e4eadcfb
  23. 23 Aug, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #30396. · 4a7fdf86
      gshchepa/uchum@gleb.loc authored
      Recommit to 5.1.22.
      The bug caused memory corruption for some queries with top OR level
      in the WHERE condition if they contained equality predicates and 
      other sargable predicates in disjunctive parts of the condition.
      
      The corruption happened because the upper bound of the memory
      allocated for KEY_FIELD and SARGABLE_PARAM internal structures
      containing info about potential lookup keys was calculated incorrectly
      in some cases. In particular it was calculated incorrectly when the
      WHERE condition was an OR formula with disjuncts being AND formulas
      including equalities and other sargable predicates.
      4a7fdf86
  24. 15 Aug, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #30396. · d790ec42
      igor@olga.mysql.com authored
      The bug caused memory corruption for some queries with top OR level
      in the WHERE condition if they contained equality predicates and 
      other sargable predicates in disjunctive parts of the condition.
      
      The corruption happened because the upper bound of the memory
      allocated for KEY_FIELD and SARGABLE_PARAM internal structures
      containing info about potential lookup keys was calculated incorrectly
      in some cases. In particular it was calculated incorrectly when the
      WHERE condition was an OR formula with disjuncts being AND formulas
      including equalities and other sargable predicates.
      d790ec42
  25. 02 Aug, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #27352. · b63f8f89
      gshchepa/uchum@gleb.loc authored
      The SELECT query with more than 31 nested dependent SELECT queries returned
      wrong result.
      
      New error message has been added: ER_TOO_HIGH_LEVEL_OF_NESTING_FOR_SELECT.
      It will be reported as: "Too high level of nesting for select".
      b63f8f89
  26. 10 Apr, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #19372: · 9514ac9f
      gkodinov/kgeorge@magare.gmz authored
      Added a test case.
      The problem was fixed by the fix for bug #17379.
      The problem was that because of some conditions 
      the optimizer always preferred range or full index
      scan access methods to lookup access methods even
      when the latter were much cheaper.
      9514ac9f
  27. 26 Mar, 2007 1 commit
  28. 12 Mar, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #26963: invalid optimization of the pushdown conditions · e7284ace
      igor@olga.mysql.com authored
      after single-row table substitution could lead to a wrong result set.
      The bug happened because the function Item_field::replace_equal_field
      erroniously assumed that any field included in a multiple equality
      with a constant has been already substituted for this constant.
      This not true for fields becoming constant after row substitutions
      for constant tables.
       
      e7284ace
  29. 09 Mar, 2007 1 commit
  30. 15 Feb, 2007 1 commit
  31. 13 Feb, 2007 1 commit
  32. 06 Feb, 2007 1 commit
  33. 01 Feb, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #25407. · 71013621
      igor@olga.mysql.com authored
      The bug could cause choosing a sub-optimal execution plan for 
      a single-table query if a unique index with many null keys were 
      defined for the table. 
      It happened because the code of the check_quick_keys function 
      made an assumption that any key may occur in an unique index 
      only once. Yet this is not true for keys with nulls that may 
      have multiple occurrences in the index.
      71013621
  34. 22 Jan, 2007 1 commit
  35. 19 Jan, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#25172: Not checked buffer size leads to a server crash. · d7d5db64
      evgen@moonbone.local authored
      After fix for bug#21798 JOIN stores the pointer to the buffer for sorting
      fields. It is used while sorting for grouping and for ordering. If ORDER BY
      clause has more elements then the GROUP BY clause then a memory overrun occurs.
      
      Now the length of the ORDER BY list is always passed to the 
      make_unireg_sortorder() function and it allocates buffer big enough to be
      used for bigger list.
      d7d5db64
  36. 03 Jan, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#6298 (LIMIT #, -1 no longer works to set start with no end limit) · 236000ae
      malff/marcsql@weblab.(none) authored
      With MySQL 3.23 and 4.0, the syntax 'LIMIT N, -1' is accepted, and returns
      all the rows located after row N. This behavior, however, is not the
      intended result, and defeats the purpose of LIMIT, which is to constrain
      the size of a result set.
      
      With MySQL 4.1 and later, this construct is correctly detected as a syntax
      error.
      
      This fix does not change the production code, and only adds a new test case
      to improve test coverage in this area, to enforce in the test suite the
      intended behavior.
      236000ae
  37. 06 Dec, 2006 1 commit