An error occurred fetching the project authors.
  1. 16 Sep, 2010 1 commit
    • Sergey Glukhov's avatar
      Bug#50402 Optimizer producing wrong results when using Index Merge on InnoDB · 31a38c0f
      Sergey Glukhov authored
      Subselect executes twice, at JOIN::optimize stage
      and at JOIN::execute stage. At optimize stage
      Innodb prebuilt struct which is used for the
      retrieval of column values is initialized in.
      ha_innobase::index_read(), prebuilt->sql_stat_start is true.
      After QUICK_ROR_INTERSECT_SELECT finished his job it
      restores read_set/write_set bitmaps with initial values
      and deactivates one of the handlers used by
      QUICK_ROR_INTERSECT_SELECT in JOIN::cleanup
      (it's the case when we reuse original handler as one of
       handlers required by QUICK_ROR_INTERSECT_SELECT object).
      On second subselect execution inactive handler is activated
      in  QUICK_RANGE_SELECT::reset, file->ha_index_init().
      In ha_index_init Innodb prebuilt struct is reinitialized
      with inappropriate read_set/write_set bitmaps. Further
      reinitialization in ha_innobase::index_read() does not
      happen as prebuilt->sql_stat_start is false.
      It leads to partial retrieval of required field values
      and we get a mix of field values from different records
      in the record buffer.
      The fix is to reset
      read_set/write_set bitmaps as these values
      are required for proper intialization of
      internal InnoDB struct which is used for
      the retrieval of column values
      (see build_template(), ha_innodb.cc)
      
      
      mysql-test/include/index_merge_ror_cpk.inc:
        test case
      mysql-test/r/index_merge_innodb.result:
        test case
      mysql-test/r/index_merge_myisam.result:
        test case
      sql/opt_range.cc:
        if ROR merge scan is used we need to reset
        read_set/write_set bitmaps as these values
        are required for proper intialization of
        internal InnoDB struct which is used for
        the retrieval of column values
        (see build_template(), ha_innodb.cc)
      31a38c0f
  2. 24 Aug, 2010 1 commit
    • Alexey Kopytov's avatar
      Bug #54802: 'NOT BETWEEN' evaluation is incorrect · e7b26882
      Alexey Kopytov authored
      Queries involving predicates of the form "const NOT BETWEEN
      not_indexed_column AND indexed_column" could return wrong data
      due to incorrect handling by the range optimizer.
      
      For "c NOT BETWEEN f1 AND f2" predicates, get_mm_tree()
      produces a disjunction of the SEL_ARG trees for "f1 > c" and
      "f2 < c". If one of the trees is empty (i.e. one of the
      arguments is not sargable) the resulting tree should be empty
      as well, since the whole expression in this case is not
      sargable.
      
      The above logic is implemented in get_mm_tree() as follows. The
      initial state of the resulting tree is NULL (aka empty). We
      then iterate through arguments and compute the corresponding
      SEL_ARG tree (either "f1 > c" or "f2 < c"). If the resulting
      tree is NULL, it is simply replaced by the generated
      tree. Otherwise it is replaced by a disjunction of itself and
      the generated tree. The obvious flaw in this implementation is
      that if the first argument is not sargable and thus produces a
      NULL tree, the resulting tree will simply be replaced by the
      tree for the second argument. As a result, "c NOT BETWEEN f1
      AND f2" will end up as just "f2 < c".
      
      Fixed by adding a check so that when the first argument
      produces an empty tree for the NOT BETWEEN case, the loop is
      aborted with an empty tree as a result. The whole idea of using
      a loop for 2 arguments does not make much sense, but it was
      probably used to avoid code duplication for several BETWEEN
      variants.
      e7b26882
  3. 15 Jul, 2010 1 commit
    • Alexey Kopytov's avatar
      Backport of the fix for bug#25421 to 5.0. · 4c28b677
      Alexey Kopytov 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.
      4c28b677
  4. 24 Jun, 2010 1 commit
    • Martin Hansson's avatar
      Bug#41660: Sort-index_merge for non-first join table may · 2b734bbe
      Martin Hansson authored
      require O(#scans) memory
      
      When an index merge operation was restarted, it would
      re-allocate the Unique object controlling the duplicate row
      ID elimination. Fixed by making the Unique object a member
      of QUICK_INDEX_MERGE_SELECT and thus reusing it throughout
      the lifetime of this object.
      2b734bbe
  5. 21 Jun, 2010 1 commit
    • Sergey Glukhov's avatar
      Bug#50389 Using intersect does not return all rows · b36a0282
      Sergey Glukhov authored
      In process of record search it is not taken into account
      that inital quick->file->ref value could be inapplicable
      to range interval. After proper row is found this value is
      stored into the record buffer and later the record is
      filtered out at condition evaluation stage.
      The fix is store a refernce of found row to the handler ref field.
      
      
      mysql-test/r/innodb_mysql.result:
        test case
      mysql-test/std_data/intersect-bug50389.tsv:
        test case
      mysql-test/t/innodb_mysql.test:
        test case
      sql/opt_range.cc:
        store a refernce of found row to the handler ref field.
      b36a0282
  6. 10 May, 2010 1 commit
    • Martin Hansson's avatar
      Bug#50939: Loose Index Scan unduly relies on engine to · 6d0425b1
      Martin Hansson authored
      remember range endpoints
      
      The Loose Index Scan optimization keeps track of a sequence
      of intervals. For the current interval it maintains the
      current interval's endpoints. But the maximum endpoint was
      not stored in the SQL layer; rather, it relied on the
      storage engine to retain this value in-between reads. By
      coincidence this holds for MyISAM and InnoDB. Not for the
      partitioning engine, however.
      
      Fixed by making the key values iterator 
      (QUICK_RANGE_SELECT) keep track of the current maximum endpoint.
      This is also more efficient as we save a call through the
      handler API in case of open-ended intervals.
      
      The code to calculate endpoints was extracted into 
      separate methods in QUICK_RANGE_SELECT, and it was possible to
      get rid of some code duplication as part of fix.
      6d0425b1
  7. 09 Feb, 2010 1 commit
    • Sergey Vojtovich's avatar
      BUG#49902 - SELECT returns incorrect results · 0897669c
      Sergey Vojtovich authored
      Queries optimized with GROUP_MIN_MAX didn't cleanup KEYREAD
      optimization properly. As a result subsequent queries may
      return incomplete rows (fields are initialized to default
      values).
      
      mysql-test/r/group_min_max.result:
        A test case for BUG#49902.
      mysql-test/t/group_min_max.test:
        A test case for BUG#49902.
      sql/opt_range.cc:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      sql/opt_sum.cc:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      sql/sql_select.cc:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      sql/sql_update.cc:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      sql/table.cc:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      sql/table.h:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      0897669c
  8. 03 Feb, 2010 1 commit
    • MySQL Build Team's avatar
      Backport into build-201002030816-5.0.87sp1 · f483141b
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 2818.1.5
      > revision-id: ramil@mysql.com-20091023112648-gie6o3odj57cxh1e
      > parent: ramil@mysql.com-20091021090408-208mvwwrcroi2j8c
      > committer: Ramil Kalimullin <ramil@mysql.com>
      > branch nick: b48258-5.0-bugteam
      > timestamp: Fri 2009-10-23 16:26:48 +0500
      > message:
      >   Fix for bug#48258: Assertion failed when using a spatial index
      >   
      >   Problem: involving a spatial index for "non-spatial" queries
      >   (that don't containt MBRXXX() functions) may lead to failed assert.
      >   
      >   Fix: don't use spatial indexes in such cases.
      f483141b
  9. 25 Nov, 2009 4 commits
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · 49383941
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 3181
      > revision-id: alexey.kopytov@sun.com-20091016201951-fsht0wm8xn8vkzsx
      > parent: joerg@mysql.com-20091016164025-kb4sbrggq5o7zufc
      > committer: Alexey Kopytov <Alexey.Kopytov@Sun.com>
      > branch nick: mysql-5.1-bugteam
      > timestamp: Sat 2009-10-17 00:19:51 +0400
      > message:
      >   Bug #47123: Endless 100% CPU loop with STRAIGHT_JOIN 
      >    
      >   The problem was in incorrect handling of predicates involving 
      >   NULL as a constant value by the range optimizer. 
      >    
      >   For example, when creating a SEL_ARG node from a condition of 
      >   the form "field < const" (which would normally result in the 
      >   "NULL < field < const" SEL_ARG),  the special case when "const" 
      >   is NULL was not taken into account, so "NULL < field < NULL" 
      >   was produced for the "field < NULL" condition. 
      >    
      >   As a result, SEL_ARG structures of this form could not be 
      >   further optimized which in turn could lead to incorrectly 
      >   constructed SEL_ARG trees. In particular, code assuming SEL_ARG 
      >   structures to always form a sequence of ordered disjoint 
      >   intervals could enter an infinite loop under some 
      >   circumstances. 
      >    
      >   Fixed by changing get_mm_leaf() so that for any sargable 
      >   predicate except "<=>" involving NULL as a constant, "empty" 
      >   SEL_ARG is returned, since such a predicate is always false. 
      49383941
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · 37066594
      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.
      37066594
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · e24d997f
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 1810.3959.5
      > revision-id: ramil@mysql.com-20091023112648-gie6o3odj57cxh1e
      > parent: ramil@mysql.com-20091021090408-208mvwwrcroi2j8c
      > committer: Ramil Kalimullin <ramil@mysql.com>
      > branch nick: b48258-5.0-bugteam
      > timestamp: Fri 2009-10-23 16:26:48 +0500
      > message:
      >   Fix for bug#48258: Assertion failed when using a spatial index
      >   
      >   Problem: involving a spatial index for "non-spatial" queries
      >   (that don't containt MBRXXX() functions) may lead to failed assert.
      >   
      >   Fix: don't use spatial indexes in such cases.
      e24d997f
    • Martin Hansson's avatar
      Bug#48459: valgrind errors with query using 'Range checked · 14f2eb12
      Martin Hansson authored
      for each record'
      
      There was an error in an internal structure in the range
      optimizer (SEL_ARG). Bad design causes parts of a data
      structure not to be initialized when it is in a certain
      state. All client code must check that this state is not
      present before trying to access the structure's data. Fixed
      by
      
      - Checking the state before trying to access data (in
      several places, most of which not covered by test case.)
      
      - Copying the keypart id when cloning SEL_ARGs
      
      
      mysql-test/r/range.result:
        Bug#48459: Test result.
      mysql-test/t/range.test:
        Bug#48459: Test case.
      sql/opt_range.cc:
        Bug#48459: Fix + doxygenated count_key_part_usage comment.
      14f2eb12
  10. 19 Nov, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #48665: sql-bench's insert test fails due to wrong result · 405c9310
      Georgi Kodinov authored
      When merging ranges during calculation of the result of OR
      to two range sets the current range may be obsoleted by the 
      resulting merged range.
      The first overlapping range can be obsoleted as well.
      
      Fixed by moving the pointer to the first overlapping range to the
      pointer of the resulting union range.
      Added few comments at key places in key_or().
      405c9310
  11. 17 Nov, 2009 1 commit
    • Alexey Kopytov's avatar
      Bug #48472: Loose index scan inappropriately chosen for some · 8cfa50e6
      Alexey Kopytov authored
                  WHERE conditions 
       
      check_group_min_max() checks if the loose index scan 
      optimization is applicable for a given WHERE condition, that is 
      if the MIN/MAX attribute participates only in range predicates 
      comparing the corresponding field with constants. 
       
      The problem was that it considered the whole predicate suitable 
      for the loose index scan optimization as soon as it encountered 
      a constant as a predicate argument. This is obviously wrong for 
      cases when a constant is the first argument of a predicate 
      which does not satisfy the above condition. 
       
      Fixed check_group_min_max() so that all arguments of the input 
      predicate are considered to decide if it passes the test, even 
      though a constant has already been encountered.
      
      mysql-test/r/group_min_max.result:
        Added a test case for bug #48472.
      mysql-test/t/group_min_max.test:
        Added a test case for bug #48472.
      sql/opt_range.cc:
        Fixed check_group_min_max() so that all arguments of the input 
        predicate are considered to decide if it passes the test, even 
        though a constant has already been encountered.
      8cfa50e6
  12. 02 Nov, 2009 1 commit
    • Martin Hansson's avatar
      Bug#47925: regression of range optimizer and date comparison in 5.1.39! · 740b7c4e
      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.
      
      
      mysql-test/r/range.result:
        Bug#47925: Test result
      mysql-test/t/range.test:
        Bug#47925: Test case
      sql/item.cc:
        Bug#47925: Fix + some edit on the comments
      sql/item.h:
        Bug#47925: Changed function signature
      sql/item_cmpfunc.cc:
        Bug#47925: Split function in two
      sql/item_cmpfunc.h:
        Bug#47925: Declaration of new function
      sql/opt_range.cc:
        Bug#47925: Added THD to function call
      sql/time.cc:
        Bug#47925: Added microsecond comparison
      740b7c4e
  13. 23 Oct, 2009 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug#48258: Assertion failed when using a spatial index · b7ce2a01
      Ramil Kalimullin authored
      Problem: involving a spatial index for "non-spatial" queries
      (that don't containt MBRXXX() functions) may lead to failed assert.
      
      Fix: don't use spatial indexes in such cases.
      
      
      mysql-test/r/gis-rtree.result:
        Fix for bug#48258: Assertion failed when using a spatial index
          - test result.
      mysql-test/t/gis-rtree.test:
        Fix for bug#48258: Assertion failed when using a spatial index
          - test case.
      sql/opt_range.cc:
        Fix for bug#48258: Assertion failed when using a spatial index
          - allow only spatial functions (MBRXXX) for itMBR keyparts.
      b7ce2a01
  14. 16 Oct, 2009 2 commits
    • Alexey Kopytov's avatar
      Bug #47123: Endless 100% CPU loop with STRAIGHT_JOIN · f6868a4e
      Alexey Kopytov authored
       
      The problem was in incorrect handling of predicates involving 
      NULL as a constant value by the range optimizer. 
       
      For example, when creating a SEL_ARG node from a condition of 
      the form "field < const" (which would normally result in the 
      "NULL < field < const" SEL_ARG),  the special case when "const" 
      is NULL was not taken into account, so "NULL < field < NULL" 
      was produced for the "field < NULL" condition. 
       
      As a result, SEL_ARG structures of this form could not be 
      further optimized which in turn could lead to incorrectly 
      constructed SEL_ARG trees. In particular, code assuming SEL_ARG 
      structures to always form a sequence of ordered disjoint 
      intervals could enter an infinite loop under some 
      circumstances. 
       
      Fixed by changing get_mm_leaf() so that for any sargable 
      predicate except "<=>" involving NULL as a constant, "empty" 
      SEL_ARG is returned, since such a predicate is always false. 
      
      mysql-test/r/partition_pruning.result:
        Fixed a broken test case.
      mysql-test/r/range.result:
        Added a test case for bug #47123.
      mysql-test/r/subselect.result:
        Fixed a broken test cases.
      mysql-test/t/range.test:
        Added a test case for bug #47123.
      sql/opt_range.cc:
        Fixed get_mm_leaf() so that for any sargable
        predicate except "<=>" involving NULL as a constant, "empty"
        SEL_ARG is returned, since such a predicate is always false.
      f6868a4e
    • Georgi Kodinov's avatar
  15. 13 Oct, 2009 1 commit
    • Alexey Kopytov's avatar
      Bug #47123: Endless 100% CPU loop with STRAIGHT_JOIN · bc9f56a6
      Alexey Kopytov authored
       
      The problem was in incorrect handling of predicates involving 
      NULL as a constant value by the range optimizer.  
       
      For example, when creating a SEL_ARG node from a condition of 
      the form "field < const" (which would normally result in the 
      "NULL < field < const" SEL_ARG),  the special case when "const" 
      is NULL was not taken into account, so "NULL < field < NULL" 
      was produced for the "field < NULL" condition. 
       
      As a result, SEL_ARG structures of this form could not be 
      further optimized which in turn could lead to incorrectly 
      constructed SEL_ARG trees. In particular, code assuming SEL_ARG 
      structures to always form a sequence of ordered disjoint 
      intervals could enter an infinite loop under some 
      circumstances. 
       
      Fixed by changing get_mm_leaf() so that for any sargable 
      predicate except "<=>" involving NULL as a constant, "empty" 
      SEL_ARG is returned, since such a predicate is always false. 
      
      mysql-test/r/range.result:
        Added a test case for bug #47123.
      mysql-test/t/range.test:
        Added a test case for bug #47123.
      sql/opt_range.cc:
        Fixed get_mm_leaf() so that for any sargable 
        predicate except "<=>" involving NULL as a constant, "empty" 
        SEL_ARG is returned, since such a predicate is always false.
      bc9f56a6
  16. 09 Oct, 2009 1 commit
    • Martin Hansson's avatar
      Bug#42846: wrong result returned for range scan when using · 5ef9ec9d
      Martin Hansson authored
      covering index
            
      When two range predicates were combined under an OR
      predicate, the algorithm tried to merge overlapping ranges
      into one. But the case when a range overlapped several other
      ranges was not handled. This lead to
      
      1) ranges overlapping, which gave repeated results and 
      2) a range that overlapped several other ranges was cut off.  
      
      Fixed by 
      
      1) Making sure that a range got an upper bound equal to the
      next range with a greater minimum.
      2) Removing a continue statement
      
      
      mysql-test/r/group_min_max.result:
        Bug#42846: Changed query plans
      mysql-test/r/range.result:
        Bug#42846: Test result.
      mysql-test/t/range.test:
        Bug#42846: Test case.
      sql/opt_range.cc:
        Bug#42846: The fix. 
        
        Part1: Previously, both endpoints from key2 were copied,
        which is not safe. Since ranges are processed in ascending
        order of minimum endpoints, it is safe to copy the minimum
        endpoint from key2 but not the maximum. The maximum may only
        be copied if there is no other range or the other range's
        minimum is greater than key2's maximum.
      5ef9ec9d
  17. 08 Oct, 2009 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug #42803: Field_bit does not have unsigned_flag field, · 3185118e
      Ramil Kalimullin authored
      can lead to bad memory access
      
      Problem: Field_bit is the only field which returns INT_RESULT
      and doesn't have unsigned flag. As it's not a descendant of the 
      Field_num, so using ((Field_num *) field_bit)->unsigned_flag may lead
      to unpredictable results.
      
      Fix: check the field type before casting.
      
      
      mysql-test/r/type_bit.result:
        Fix for bug #42803: Field_bit does not have unsigned_flag field,
        can lead to bad memory access
          - test result.
      mysql-test/t/type_bit.test:
        Fix for bug #42803: Field_bit does not have unsigned_flag field,
        can lead to bad memory access
          - test case.
      sql/opt_range.cc:
        Fix for bug #42803: Field_bit does not have unsigned_flag field,
        can lead to bad memory access
          - don't cast to (Field_num *) Field_bit, as it's not a Field_num
        descendant and is always unsigned by nature.
      3185118e
  18. 30 Aug, 2009 1 commit
    • Alexey Kopytov's avatar
      Bug #46607: Assertion failed: (cond_type == Item::FUNC_ITEM) · 6ce48392
      Alexey Kopytov authored
                  results in server crash 
       
      check_group_min_max_predicates() assumed the input condition 
      item to be one of COND_ITEM, SUBSELECT_ITEM, or FUNC_ITEM. 
      Since a condition of the form "field" is also a valid condition 
      equivalent to "field <> 0", using such a condition in a query 
      where the loose index scan was chosen resulted in a debug 
      assertion failure. 
       
      Fixed by handling conditions of the FIELD_ITEM type in 
      check_group_min_max_predicates(). 
      
      mysql-test/r/group_min_max.result:
        Added a test case for bug #46607.
      mysql-test/t/group_min_max.test:
        Added a test case for bug #46607.
      sql/opt_range.cc:
        Handle conditions of the FUNC_ITEM type in 
        check_group_mix_max_predicates().
      6ce48392
  19. 28 Aug, 2009 1 commit
    • Staale Smedseng's avatar
      Bug #43414 Parenthesis (and other) warnings compiling MySQL · 1ba25ae4
      Staale Smedseng authored
      with gcc 4.3.2
            
      This patch fixes a number of GCC warnings about variables used
      before initialized. A new macro UNINIT_VAR() is introduced for
      use in the variable declaration, and LINT_INIT() usage will be
      gradually deprecated. (A workaround is used for g++, pending a
      patch for a g++ bug.)
            
      GCC warnings for unused results (attribute warn_unused_result)
      for a number of system calls (present at least in later
      Ubuntus, where the usual void cast trick doesn't work) are
      also fixed.
      
      
      client/mysqlmanager-pwgen.c:
        A fix for warn_unused_result, adding fallback to use of
        srand()/rand() if /dev/random cannot be used. Also actually
        adds calls to rand() in the second branch so that it actually
        creates a random password.
      1ba25ae4
  20. 26 Aug, 2009 2 commits
    • Mattias Jonsson's avatar
      Bug#20577: Partitions: use of to_days() function leads to selection failures · 67214ef4
      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).
      
      mysql-test/include/partition_date_range.inc:
        Bug#20577: Partitions: use of to_days() function leads to selection failures
        
        Added include file to decrease test code duplication
      mysql-test/r/partition_pruning.result:
        Bug#20577: Partitions: use of to_days() function leads to selection failures
        
        Added test results
      mysql-test/r/partition_range.result:
        Bug#20577: Partitions: use of to_days() function leads to selection failures
        
        Updated test result.
        This fix adds the partition containing NULL values to
        the list of partitions to be scanned.
      mysql-test/t/partition_pruning.test:
        Bug#20577: Partitions: use of to_days() function leads to selection failures
        
        Added test case
      sql/item.h:
        Bug#20577: Partitions: use of to_days() function leads to selection failures
        
        Added MONOTONIC_*INCREASE_NOT_NULL values to be used by TO_DAYS.
      sql/item_timefunc.cc:
        Bug#20577: Partitions: use of to_days() function leads to selection failures
        
        Calculate the number of days as return value even for invalid dates.
        This is so that pruning can be used even for invalid dates.
      sql/opt_range.cc:
        Bug#20577: Partitions: use of to_days() function leads to selection failures
        
        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).
      sql/partition_info.h:
        Bug#20577: Partitions: use of to_days() function leads to selection failures
        
        Resetting ret_null_part when a single partition is to be used, this
        to avoid adding the NULL partition.
      sql/sql_partition.cc:
        Bug#20577: Partitions: use of to_days() function leads to selection failures
        
        Always include the NULL partition if RANGE or LIST.
        Use the returned value for the function for pruning, even if
        it is marked as NULL, so that even '2000-00-00' can be
        used for pruning, even if TO_DAYS('2000-00-00') is NULL.
        
        Changed == to >= in get_next_partition_id_list to avoid
        crash if part_iter->part_nums is not correctly setup.
      67214ef4
    • Mattias Jonsson's avatar
      Bug#46362: Endpoint should be set to false for TO_DAYS(DATE) · 4655118b
      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 '>='.
      
      mysql-test/r/partition_pruning.result:
        Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
        
        Updated result-file
      mysql-test/t/partition_pruning.test:
        Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
        
        Added testcases.
      sql-common/my_time.c:
        Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
        
        removed duplicate assignment.
      sql/item.cc:
        Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
        
        Changed field_is_equal_to_item into field_cmp_to_item, to
        better handling DATE vs DATETIME comparision.
      sql/item.h:
        Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
        
        Updated comment
      sql/item_timefunc.cc:
        Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
        
        Added optimization (pruning) of DATETIME where time-part is
        23:59:59
      sql/opt_range.cc:
        Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
        
        Using the new stored_field_cmp_to_item for better pruning.
      4655118b
  21. 24 Aug, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #37044: Read overflow in opt_range.cc found during "make test" · 7492d622
      Georgi Kodinov authored
      The code was using a special global buffer for the value of IS NULL ranges.
      This was not always long enough to be copied by a regular memcpy. As a 
      result read buffer overflows may occur.
      Fixed by setting the null byte to 1 and setting the rest of the field disk image
      to NULL with a bzero (instead of relying on the buffer and memcpy()).
      7492d622
  22. 19 Aug, 2009 1 commit
  23. 16 Jul, 2009 1 commit
  24. 09 Jul, 2009 1 commit
  25. 12 Jun, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #45386: Wrong query result with MIN function in field list, · 3e82a86e
      Georgi Kodinov authored
      WHERE and GROUP BY clause
      
      Loose index scan may use range conditions on the argument of 
      the MIN/MAX aggregate functions to find the beginning/end of 
      the interval that satisfies the range conditions in a single go.
      These range conditions may have open or closed minimum/maximum 
      values. When the comparison returns 0 (equal) the code should 
      check the type of the min/max values of the current interval 
      and accept or reject the row based on whether the limit is 
      open or not.
      There was a wrong composite condition on checking this and it was
      not working in all cases.
      Fixed by simplifying the conditions and reversing the logic.
      
      mysql-test/r/group_min_max.result:
        Bug #45386: test case
      mysql-test/t/group_min_max.test:
        Bug #45386: test case
      sql/opt_range.cc:
        Bug #45386: fix the check whether to use the value if on the
        interval boundry
      3e82a86e
  26. 10 Jun, 2009 1 commit
    • Martin Hansson's avatar
      Bug#44821: select distinct on partitioned table returns wrong results · f2448c93
      Martin Hansson authored
      Range analysis did not request sorted output from the storage engine,
      which cause partitioned handlers to process one partition at a time
      while reading key prefixes in ascending order, causing values to be 
      missed. Fixed by always requesting sorted order during range analysis.
      This fix is introduced in 6.0 by the fix for bug no 41136.
      
      mysql-test/r/group_min_max.result:
        Bug#44821: Test result.
      mysql-test/t/group_min_max.test:
        Bug#44821: Test case
      sql/opt_range.cc:
        Bug#44821: Fix.
      f2448c93
  27. 09 Jun, 2009 2 commits
    • Staale Smedseng's avatar
      Bug #43414 Parenthesis (and other) warnings compiling MySQL · a073ee45
      Staale Smedseng authored
      with gcc 4.3.2
            
      Compiling MySQL with gcc 4.3.2 and later produces a number of 
      warnings, many of which are new with the recent compiler
      versions.
            
      This bug will be resolved in more than one patch to limit the
      size of changesets. This is the first patch, fixing a number 
      of the warnings, predominantly "suggest using parentheses 
      around && in ||", and empty for and while bodies.
      a073ee45
    • Staale Smedseng's avatar
      Bug #43414 Parenthesis (and other) warnings compiling MySQL · a092ed1a
      Staale Smedseng authored
      with gcc 4.3.2
      
      Compiling MySQL with gcc 4.3.2 and later produces a number of 
      warnings, many of which are new with the recent compiler
      versions.
      
      This bug will be resolved in more than one patch to limit the
      size of changesets. This is the first patch, fixing a number 
      of the warnings, predominantly "suggest using parentheses 
      around && in ||", and empty for and while bodies.
      a092ed1a
  28. 30 Apr, 2009 1 commit
  29. 11 Mar, 2009 1 commit
  30. 27 Feb, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #41610: key_infix_len can be overwritten causing some group by queries to · 15760fe9
      Georgi Kodinov authored
      return no rows
      
      The algorithm of determining the best key for loose index scan is doing a loop
      over the available indexes and selects the one that has the best cost.
      It retrieves the parameters of the current index into a set of variables.
      If the cost of using the current index is lower than the best cost so far it 
      copies these variables into another set of variables that contain the 
      information for the best index so far.
      After having checked all the indexes it uses these variables (outside of the 
      index loop) to create the table read plan object instance.
      The was a single omission : the key_infix/key_infix_len variables were used 
      outside of the loop without being preserved in the loop for the best index 
      so far.
      This causes these variables to get overwritten by the next index(es) checked.
      Fixed by adding variables to hold the data for the current index, passing 
      the new variables to the function that assigns values to them and copying 
      the new variables into the existing ones when selecting a new current best 
      index.
      To avoid further such problems moved the declarations of the variables used 
      to keep information about the current index inside the loop's compound 
      statement.
      
      mysql-test/r/group_min_max.result:
        Bug #41610: test case
      mysql-test/t/group_min_max.test:
        Bug #41610: test case
      sql/opt_range.cc:
        Bug #41610: copy the infix data for the current best index
      15760fe9
  31. 23 Feb, 2009 1 commit
    • Sergey Petrunia's avatar
      - Backport @@optimizer_switch support from 6.0 · cb6581d8
      Sergey Petrunia authored
      - Add support for setting it as a server commandline argument
      - Add support for those switches:
        = no_index_merge
        = no_index_merge_union
        = no_index_merge_sort_union
        = no_index_merge_intersection
      
      mysql-test/r/index_merge_myisam.result:
        Testcases for index_merge related @@optimizer_switch flags.
      mysql-test/t/index_merge_myisam.test:
        Testcases for index_merge related @@optimizer_switch flags.
      sql/set_var.cc:
        - Backport @@optimizer_switch support from 6.0
        - Add support for setting it as a server commandline argument
      sql/sql_class.h:
        - Backport @@optimizer_switch support from 6.0
      sql/sql_select.h:
        - Backport @@optimizer_switch support from 6.0
      cb6581d8
  32. 10 Feb, 2009 1 commit
  33. 19 Dec, 2008 1 commit
    • Sergey Petrunia's avatar
      BUG#40974: Incorrect query results when using clause evaluated using range check · 7976735a
      Sergey Petrunia authored
      - QUICK_INDEX_MERGE_SELECT deinitializes its rnd_pos() scan when it reaches EOF, but we 
        need to make the deinitialization in QUICK_INDEX_MERGE_SELECT destructor also. This is because
        certain execution strategies can stop scanning without reaching EOF, then then try to do a full
        table scan on this table. Failure to deinitialize caused the full scan to use (already empty) 
        table->sort and produce zero records.
      
      mysql-test/r/index_merge.result:
        BUG#40974: Incorrect query results when using clause evaluated using range check
        - Testcase
      mysql-test/t/index_merge.test:
        BUG#40974: Incorrect query results when using clause evaluated using range check
        - Testcase
      7976735a
  34. 09 Dec, 2008 1 commit