An error occurred fetching the project authors.
  1. 27 Nov, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #32403: query causes a crash due to stack and · 97ac0c27
      gshchepa/uchum@gleb.loc authored
                        memory corruptions.
      
      The right pointer field of the SEL_ARG structure was not
      initialized in the constructor and sometimes that led to
      server crashes.
      
      There is no testcase because the bug occurs only when
      uninitialized memory has particular values, which can't be
      re-created in the test suite.
      97ac0c27
  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. 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
  4. 23 Oct, 2007 3 commits
  5. 12 Sep, 2007 1 commit
  6. 10 Sep, 2007 1 commit
  7. 15 Aug, 2007 1 commit
    • mhansson/martin@linux-st28.site's avatar
      bug#28570: handler::index_read() is called with different find_flag when · 1da8451d
      mhansson/martin@linux-st28.site authored
      ORDER BY is used
      
      The range analysis module did not correctly signal to the 
      handler that a range represents a ref (EQ_RANGE flag). This causes 
      non-range queries like 
      SELECT ... FROM ... WHERE keypart_1=const, ..., keypart_n=const 
      ORDER BY ... FOR UPDATE
      to wait for a lock unneccesarily if another running transaction uses
      SELECT ... FOR UPDATE on the same table.
      
      Fixed by setting EQ_RANGE for all range accesses that represent 
      an equality predicate. 
      1da8451d
  8. 27 Jul, 2007 1 commit
    • kostja@bodhi.(none)'s avatar
      A fix and a test case for Bug#24918 drop table and lock / inconsistent · 11c57540
      kostja@bodhi.(none) authored
      between perm and temp tables. Review fixes.
      
      The original bug report complains that if we locked a temporary table
      with LOCK TABLES statement, we would not leave LOCK TABLES mode
      when this temporary table is dropped.
      
      Additionally, the bug was escalated when it was discovered than
      when a temporary transactional table that was previously
      locked with LOCK TABLES statement was dropped, futher actions with
      this table, such as UNLOCK TABLES, would lead to a crash.
      
      The problem originates from incomplete support of transactional temporary
      tables. When we added calls to handler::store_lock()/handler::external_lock()
      to operations that work with such tables, we only covered the normal
      server code flow and did not cover LOCK TABLES mode. 
      In LOCK TABLES mode, ::external_lock(LOCK) would sometimes be called without
      matching ::external_lock(UNLOCK), e.g. when a transactional temporary table
      was dropped. Additionally, this table would be left in the list of LOCKed 
      TABLES.
      
      The patch aims to address this inadequacy. Now, whenever an instance
      of 'handler' is destroyed, we assert that it was priorly
      external_lock(UNLOCK)-ed. All the places that violate this assert
      were fixed.
      
      This patch introduces no changes in behavior -- the discrepancy in
      behavior will be fixed when we start calling ::store_lock()/::external_lock()
      for all tables, regardless whether they are transactional or not, 
      temporary or not.
      11c57540
  9. 17 Jul, 2007 3 commits
  10. 13 Jul, 2007 1 commit
  11. 30 Mar, 2007 1 commit
    • sergefp@mysql.com's avatar
      BUG#26624: high mem usage (crash) in range optimizer · dcb25513
      sergefp@mysql.com authored
      Pushbuild fixes: 
       - Make MAX_SEL_ARGS smaller (even 16K records_in_range() calls is 
         more than it makes sense to do in typical cases)
       - Don't call sel_arg->test_use_count() if we've already allocated 
         more than MAX_SEL_ARGs elements. The test will succeed but will take
         too much time for the test suite (and not provide much value).
      dcb25513
  12. 29 Mar, 2007 1 commit
  13. 28 Mar, 2007 1 commit
    • sergefp@mysql.com's avatar
      BUG#26624: high mem usage (crash) in range optimizer · a8d43972
      sergefp@mysql.com authored
      - Added PARAM::alloced_sel_args where we count the # of SEL_ARGs
        created by SEL_ARG tree cloning operations.
      - Made the range analyzer to shortcut and not do any more cloning 
        if we've already created MAX_SEL_ARGS SEL_ARG objects in cloning.
      - Added comments about space complexity of SEL_ARG-graph 
        representation.
      a8d43972
  14. 22 Mar, 2007 1 commit
  15. 20 Mar, 2007 1 commit
    • gkodinov/kgeorge@macbook.local's avatar
      Bug #24484: · 28962a76
      gkodinov/kgeorge@macbook.local authored
      To correctly decide which predicates can be evaluated with a given table
      the optimizer must know the exact set of tables that a predicate depends 
      on. If that mask is too wide (refer to non-existing tables) the optimizer
      can erroneously skip a predicate.
      One such case of wrong table usage mask were the aggregate functions.
      The have a all-1 mask (meaning depend on all tables, including non-existent
      ones).
      Fixed by making a real used_tables mask for the aggregates. The mask is
      constructed in the following way :
      1. OR the table dependency masks of all the arguments of the aggregate.
      2. If all the arguments of the function are from the local name resolution 
        context and it is evaluated in the same name resolution
        context where it is referenced all the tables from that name resolution 
        context are OR-ed to the dependency mask. This is to denote that an
        aggregate function depends on the number of rows it processes.
      3. Handle correctly the case of an aggregate function optimization (such that
        the aggregate function can be pre-calculated and made a constant).
      
      Made sure that an aggregate function is never a constant (unless subject of a 
      specific optimization and pre-calculation).  
      
      One other flaw was revealed and fixed in the process : references were 
      not calling the recalculation method for used_tables of their targets.
      28962a76
  16. 10 Mar, 2007 1 commit
  17. 12 Feb, 2007 1 commit
  18. 11 Feb, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #26159. · 976e747a
      igor@olga.mysql.com authored
      A wrong order of statements in QUICK_GROUP_MIN_MAX_SELECT::reset
      caused a crash when a query with DISTINCT was executed by a loose scan
      for an InnoDB table that had been emptied. 
      976e747a
  19. 02 Feb, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fix bug #24035. · 215b0a95
      igor@olga.mysql.com authored
      This performance degradation for UPDATEs could be observed in the update
      statements for which the search key cannot be converted to any valid
      value of the type of the search column, like for a  the condition
      int_fld=99999999999999999999999999, though it can be guaranteed here
      that there is no row with such a key value. 
      215b0a95
  20. 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
  21. 31 Dec, 2006 1 commit
    • kent@mysql.com/kent-amd64.(none)'s avatar
      my_strtoll10-x86.s: · 6523aca7
      kent@mysql.com/kent-amd64.(none) authored
        Corrected spelling in copyright text
      Makefile.am:
        Don't update the files from BitKeeper
      Many files:
        Removed "MySQL Finland AB & TCX DataKonsult AB" from copyright header
        Adjusted year(s) in copyright header 
      Many files:
        Added GPL copyright text
      Removed files:
        Docs/Support/colspec-fix.pl
        Docs/Support/docbook-fixup.pl
        Docs/Support/docbook-prefix.pl
        Docs/Support/docbook-split
        Docs/Support/make-docbook
        Docs/Support/make-makefile
        Docs/Support/test-make-manual
        Docs/Support/test-make-manual-de
        Docs/Support/xwf
      6523aca7
  22. 26 Dec, 2006 1 commit
  23. 23 Dec, 2006 1 commit
  24. 14 Dec, 2006 1 commit
    • monty@mysql.com/narttu.mysql.fi's avatar
      Fixed compiler warnings detected by option -Wshadow and -Wunused: · 88dd873d
      monty@mysql.com/narttu.mysql.fi authored
      - Removed not used variables and functions
      - Added #ifdef around code that is not used
      - Renamed variables and functions to avoid conflicts
      - Removed some not used arguments
      
      Fixed some class/struct warnings in ndb
      Added define IS_LONGDATA() to simplify code in libmysql.c
      
      I did run gcov on the changes and added 'purecov' comments on almost all lines that was not just variable name changes
      88dd873d
  25. 30 Nov, 2006 1 commit
  26. 28 Nov, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug#24156: Loose index scan not used with CREATE TABLE ...SELECT and similar · a6574ac6
      gkodinov/kgeorge@macbook.gmz authored
                 statements
      Currently the optimizer evaluates loose index scan only for top-level SELECT
      statements
      Extend loose index scan applicability by :
       - Test the applicability of loose scan for each sub-select, instead of the
         whole query. This change enables loose index scan for sub-queries.
       - allow non-select statements with SELECT parts (like, e.g. 
         CREATE TABLE .. SELECT ...) to use loose index scan.
      a6574ac6
  27. 27 Nov, 2006 1 commit
  28. 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
  29. 19 Oct, 2006 1 commit
    • ramil/ram@mysql.com/myoffice.izhnet.ru's avatar
      Fix for bug #20732: Partial index and long sjis search with '>' fails sometimes · 0027b6e4
      We miss some records sometimes using RANGE method if we have
      partial key segments.
      Example:
        Create table t1(a char(2), key(a(1)));
        insert into t1 values ('a'), ('xx');
        select a from t1 where a > 'x';
      We call index_read() passing 'x' key and HA_READ_AFTER_KEY flag
      in the handler::read_range_first() wich is wrong because we have
      a partial key segment for the field and might miss records like 'xx'.
      
      Fix: don't use open segments in such a case.
      0027b6e4
  30. 16 Oct, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #22342: No results returned for query using max and group by · 0e954d2c
      gkodinov/kgeorge@macbook.gmz authored
       When using index for group by and range access the server isolates    
       a set of ranges based on the conditions over the key parts of the
       index used. Then it uses only the ranges over the GROUP BY fields to
       jump from one group to another. Since the GROUP BY fields may form a
       prefix over the index, we may use only a prefix of the ranges produced
       by the range optimizer.
       Each range contains a notion on whether it includes its border values.
       The problem is that when using a range prefix, the last range is open
       because it assumes that there is a range on the next keypart. Thus when
       we use a prefix range as it is, it excludes all border values.
       The solution is when ignoring the suffix of the range conditions 
       (to jump over the GROUP BY prefix only) the server must change the 
       remaining intervals so they always contain their borders, e.g. 
       if the whole range was :
       (1,-inf) <= (<group_by_col>,<min_max_arg_col>) < (1, 3) we must make
       (1) <= (<group_by_col>) <= (1) because (a,b) < (c1,c2) means :
       a < c1 OR (a = c1 AND b < c2).
      0e954d2c
  31. 21 Sep, 2006 1 commit
    • dlenev@mockturtle.local's avatar
      Fix for bug#20670 "UPDATE using key and invoking trigger that modifies · 091ed9fb
      dlenev@mockturtle.local authored
      this key does not stop" (version for 5.0 only).
      
      UPDATE statement which WHERE clause used key and which invoked trigger
      that modified field in this key worked indefinetely.
      
      This problem occured because in cases when UPDATE statement was
      executed in update-on-the-fly mode (in which row is updated right
      during evaluation of select for WHERE clause) the new version of
      the row became visible to select representing WHERE clause and was
      updated again and again.
      We already solve this problem for UPDATE statements which does not
      invoke triggers by detecting the fact that we are going to update
      field in key used for scanning and performing update in two steps,
      during the first step we gather information about the rows to be
      updated and then doing actual updates. We also do this for
      MULTI-UPDATE and in its case we even detect situation when such
      fields are updated in triggers (actually we simply assume that
      we always update fields used in key if we have before update
      trigger).
      
      The fix simply extends this check which is done in check_if_key_used()/
      QUICK_SELECT_I::check_if_keys_used() routine/method in such way that
      it also detects cases when field used in key is updated in trigger.
      As nice side-effect we have more precise and thus more optimal
      perfomance-wise check for the MULTI-UPDATE.
      Also check_if_key_used()/QUICK_SELECT_I::check_if_keys_used() were
      renamed to is_key_used()/QUICK_SELECT_I::is_keys_used() in order to
      better reflect that boolean predicate.
      
      Note that this check is implemented in much more elegant way in 5.1 
      091ed9fb
  32. 18 Sep, 2006 1 commit
  33. 12 Sep, 2006 1 commit
    • svoj@april.(none)'s avatar
      BUG#20256 - LOCK WRITE - MyISAM · 44f167ee
      svoj@april.(none) authored
      Only MyISAM tables locked with LOCK TABLES ... WRITE were affected.
      
      A query that is optimized with index_merge doesn't reflect rows
      inserted within LOCK TABLES.
      
      MyISAM doesn't flush a state within LOCK TABLES. index_merge
      optimization creates a copy of the handler, which thus gets
      outdated MyISAM state.
      
      New handler->clone() method is introduced to fix this problem.
      For non-MyISAM storage engines it allocates a handler and opens
      it with ha_open(). For MyISAM it additionally copies MyISAM state
      pointer to cloned handler.
      44f167ee
  34. 31 Aug, 2006 1 commit
  35. 24 Aug, 2006 2 commits