An error occurred fetching the project authors.
  1. 25 Aug, 2008 1 commit
  2. 23 Jul, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug#37830 : ORDER BY ASC/DESC - no difference · 436f1dc4
      Georgi Kodinov authored
                        
      Range scan in descending order for c <= <col> <= c type of
      ranges was ignoring the DESC flag.
      However some engines like InnoDB have the primary key parts 
      as a suffix for every secondary key.
      When such primary key suffix is used for ordering ignoring 
      the DESC is not valid.
      But we generally would like to do this because it's faster.
                  
      Fixed by performing only reverse scan if the primary key is used.
      Removed some dead code in the process.
      436f1dc4
  3. 16 Jul, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug#37830 : ORDER BY ASC/DESC - no difference · 59ab9a08
      Georgi Kodinov authored
                  
      Range scan in descending order for c <= <col> <= c type of
      ranges was ignoring the DESC flag.
      However some engines like InnoDB have the primary key parts 
      as a suffix for every secondary key.
      When such primary key suffix is used for ordering ignoring 
      the DESC is not valid.
      But we generally would like to do this because it's faster.
            
      Fixed by performing only reverse scan if the primary key is used.
      Removed some dead code in the process.
      59ab9a08
  4. 15 Jul, 2008 1 commit
    • Sergey Petrunia's avatar
      BUG#35478: sort_union() returns bad data when sort_buffer_size is hit · 2951f00b
      Sergey Petrunia authored
      - In QUICK_INDEX_MERGE_SELECT::read_keys_and_merge: when we got table->sort from Unique,
        tell init_read_record() not to use rr_from_cache() because a) rowids are already sorted
        and b) it might be that the the data is used by filesort(), which will need record rowids
        (which rr_from_cache() cannot provide).
      - Fully de-initialize the table->sort read in QUICK_INDEX_MERGE_SELECT::get_next(). This fixes BUG#35477.
      (bk trigger: file as fix for BUG#35478).
      2951f00b
  5. 08 Apr, 2008 1 commit
  6. 28 Mar, 2008 1 commit
  7. 10 Mar, 2008 1 commit
  8. 13 Dec, 2007 1 commit
  9. 12 Dec, 2007 1 commit
    • kostja@bodhi.(none)'s avatar
      Bug#12713 "Error in a stored function called from a SELECT doesn't · ebb9c5d9
      kostja@bodhi.(none) authored
      cause ROLLBACK of statement", part 1. Review fixes.
      
      Do not send OK/EOF packets to the client until we reached the end of 
      the current statement.
      This is a consolidation, to keep the functionality that is shared by all 
      SQL statements in one place in the server.
      Currently this functionality includes:
      - close_thread_tables()
      - log_slow_statement().
      
      After this patch and the subsequent patch for Bug#12713, it shall also include:
      - ha_autocommit_or_rollback()
      - net_end_statement()
      - query_cache_end_of_result().
      
      In future it may also include:
      - mysql_reset_thd_for_next_command().
      ebb9c5d9
  10. 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
  11. 23 Nov, 2007 1 commit
  12. 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
  13. 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
  14. 12 Nov, 2007 1 commit
  15. 07 Nov, 2007 1 commit
    • kaa@polly.(none)'s avatar
      Fix for bug #25421: MySQL threads don't respond to the kill command · 3ebb915d
      kaa@polly.(none) authored
      Calculating the estimated number of records for a range scan may take a
      significant time, and it was impossible for a user to interrupt that
      process by killing the connection or the query.
      
      Fixed by checking the thread's 'killed' status in check_quick_keys() and
      interrupting the calculation process if it is set to a non-zero value.
      3ebb915d
  16. 23 Oct, 2007 3 commits
  17. 17 Oct, 2007 1 commit
    • kaa@polly.(none)'s avatar
      Fix for bug #31207: Test "join_nested" shows different strategy on IA64 · 6d1f3e8d
      kaa@polly.(none) authored
      CPUs / Intel's ICC compile
      
      The bug is a combination of two problems:
      
      1. IA64/ICC MySQL binaries use glibc's qsort(), not the one in mysys.
      
      2. The order relation implemented by join_tab_cmp() is not transitive,
      i.e. it is possible to choose such a, b and c that (a < b) && (b < c)
      but (c < a). This implies that result of a sort using the relation
      implemented by join_tab_cmp() depends on the order in which
      elements are compared, i.e. the result is implementation-specific. Since
      choose_plan() uses qsort() to pre-sort the
      join tables using join_tab_cmp() as a compare function, the results of
      the sorting may vary depending on qsort() implementation.
      
      It is neither possible nor important to implement a better ordering
      algorithm in join_tab_cmp(). Therefore the only way to fix it is to
      force our own qsort() to be used by renaming it to my_qsort(), so we don't depend
      on linker to decide that.
      
      This patch also "fixes" bug #20530: qsort redefinition violates the
      standard.
      6d1f3e8d
  18. 11 Oct, 2007 1 commit
    • monty@mysql.com/narttu.mysql.fi's avatar
      Moved a lot of old bug fixes and safe cleanups from Maria 5.1 tree to 5.1 · 7887babe
      monty@mysql.com/narttu.mysql.fi authored
      - Reserver namespace and place in frm for TABLE_CHECKSUM and PAGE_CHECKSUM create options
      - Added syncing of directory when creating .frm files
      - Portability fixes
      - Added missing cast that could cause bugs
      - Code cleanups
      - Made some bit functions inline
      - Moved things out of myisam.h to my_handler.h to make them more accessable
      - Renamed some myisam variables and defines to make them more globaly usable (as they are used outside of MyISAM)
      - Fixed bugs in error conditions
      - Use compiler time asserts instead of run time
      - Fixed indentation
      HA_EXTRA_PREPARE_FOR_DELETE -> HA_EXTRA_PREPARE_FOR_DROP as the old name was wrong
      (Added a define for old value to ensure we don't break any old code)
      Added HA_EXTRA_PREPARE_FOR_RENAME as a signal for rename (before we used a DROP signal which is wrong)
      - Initialize error messages early to get better errors when mysqld or an engine fails to start
      - Fix windows bug that query_performance_frequency was not initialized if registry code failed
      - thread_stack -> my_thread_stack_size
      7887babe
  19. 26 Sep, 2007 1 commit
    • gshchepa@devsrv-b.mysql.com's avatar
      Fixed bug #31075. · 7f0e9065
      gshchepa@devsrv-b.mysql.com authored
      The `SELECT col FROM t WHERE col NOT IN (col, ...) GROUP BY col'
      crashed in the range optimizer.
      
      The get_func_mm_tree function has been modified to check the
      Item_func_in::array field for the NULL value before using of that
      value.
      7f0e9065
  20. 21 Sep, 2007 2 commits
  21. 12 Sep, 2007 1 commit
  22. 10 Sep, 2007 1 commit
  23. 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
  24. 13 Aug, 2007 1 commit
    • monty@mysql.com/nosik.monty.fi's avatar
      Fixed a lot of compiler warnings and errors detected by Forte C++ on Solaris · e53a73e2
      monty@mysql.com/nosik.monty.fi authored
      Faster thr_alarm()
      Added 'Opened_files' status variable to track calls to my_open()
      Don't give warnings when running mysql_install_db
      Added option --source-install to mysql_install_db
      
      I had to do the following renames() as used polymorphism didn't work with Forte compiler on 64 bit systems
      index_read()      -> index_read_map()
      index_read_idx()  -> index_read_idx_map()
      index_read_last() -> index_read_last_map()
      e53a73e2
  25. 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
  26. 17 Jul, 2007 3 commits
  27. 13 Jul, 2007 1 commit
  28. 10 May, 2007 1 commit
    • monty@mysql.com/narttu.mysql.fi's avatar
      WL#3817: Simplify string / memory area types and make things more consistent (first part) · 088e2395
      monty@mysql.com/narttu.mysql.fi authored
      The following type conversions was done:
      
      - Changed byte to uchar
      - Changed gptr to uchar*
      - Change my_string to char *
      - Change my_size_t to size_t
      - Change size_s to size_t
      
      Removed declaration of byte, gptr, my_string, my_size_t and size_s. 
      
      Following function parameter changes was done:
      - All string functions in mysys/strings was changed to use size_t
        instead of uint for string lengths.
      - All read()/write() functions changed to use size_t (including vio).
      - All protocoll functions changed to use size_t instead of uint
      - Functions that used a pointer to a string length was changed to use size_t*
      - Changed malloc(), free() and related functions from using gptr to use void *
        as this requires fewer casts in the code and is more in line with how the
        standard functions work.
      - Added extra length argument to dirname_part() to return the length of the
        created string.
      - Changed (at least) following functions to take uchar* as argument:
        - db_dump()
        - my_net_write()
        - net_write_command()
        - net_store_data()
        - DBUG_DUMP()
        - decimal2bin() & bin2decimal()
      - Changed my_compress() and my_uncompress() to use size_t. Changed one
        argument to my_uncompress() from a pointer to a value as we only return
        one value (makes function easier to use).
      - Changed type of 'pack_data' argument to packfrm() to avoid casts.
      - Changed in readfrm() and writefrom(), ha_discover and handler::discover()
        the type for argument 'frmdata' to uchar** to avoid casts.
      - Changed most Field functions to use uchar* instead of char* (reduced a lot of
        casts).
      - Changed field->val_xxx(xxx, new_ptr) to take const pointers.
      
      Other changes:
      - Removed a lot of not needed casts
      - Added a few new cast required by other changes
      - Added some cast to my_multi_malloc() arguments for safety (as string lengths
        needs to be uint, not size_t).
      - Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done
        explicitely as this conflict was often hided by casting the function to
        hash_get_key).
      - Changed some buffers to memory regions to uchar* to avoid casts.
      - Changed some string lengths from uint to size_t.
      - Changed field->ptr to be uchar* instead of char*. This allowed us to
        get rid of a lot of casts.
      - Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar
      - Include zlib.h in some files as we needed declaration of crc32()
      - Changed MY_FILE_ERROR to be (size_t) -1.
      - Changed many variables to hold the result of my_read() / my_write() to be
        size_t. This was needed to properly detect errors (which are
        returned as (size_t) -1).
      - Removed some very old VMS code
      - Changed packfrm()/unpackfrm() to not be depending on uint size
        (portability fix)
      - Removed windows specific code to restore cursor position as this
        causes slowdown on windows and we should not mix read() and pread()
        calls anyway as this is not thread safe. Updated function comment to
        reflect this. Changed function that depended on original behavior of
        my_pwrite() to itself restore the cursor position (one such case).
      - Added some missing checking of return value of malloc().
      - Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow.
      - Changed type of table_def::m_size from my_size_t to ulong to reflect that
        m_size is the number of elements in the array, not a string/memory
        length.
      - Moved THD::max_row_length() to table.cc (as it's not depending on THD).
        Inlined max_row_length_blob() into this function.
      - More function comments
      - Fixed some compiler warnings when compiled without partitions.
      - Removed setting of LEX_STRING() arguments in declaration (portability fix).
      - Some trivial indentation/variable name changes.
      - Some trivial code simplifications:
        - Replaced some calls to alloc_root + memcpy to use
          strmake_root()/strdup_root().
        - Changed some calls from memdup() to strmake() (Safety fix)
        - Simpler loops in client-simple.c
      088e2395
  29. 16 Apr, 2007 1 commit
  30. 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
  31. 29 Mar, 2007 2 commits
  32. 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
  33. 22 Mar, 2007 1 commit
  34. 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