An error occurred fetching the project authors.
  1. 18 Jan, 2010 1 commit
  2. 22 Dec, 2009 2 commits
    • Georgi Kodinov's avatar
      Bug #49734: Crash on EXPLAIN EXTENDED UNION ... ORDER BY <any non-const-function> · 83437f46
      Georgi Kodinov authored
      Several problems fixed : 
      1. Non constant expressions in UNION ... ORDER BY were not correctly cleaned up
      in st_select_lex_unit::cleanup() causing crashes in EXPLAIN EXTENDED because of
      fields quoted by these expressions pointing to the already freed temporary table
      used to calculate the UNION.
      Fixed by correctly cleaning up expressions of any depth.
      
      2. Subqueries in the order by part of UNION ... ORDER BY ... caused a crash in 
      EXPLAIN EXTENDED because of a transformation attempt made during EXPLAIN EXTENDED
      execution. Fixed by not doing the transformation when in EXPLAIN.
      
      3. Fulltext functions caused crash when in the ORDER BY part of an un-parenthesized
      UNION that gets "promoted" to be valid for the whole union, e.g. 
      SELECT * FROM t1 UNION SELECT * FROM t2 ORDER BY MATCHES (a) AGAINST ('abc' IN BOOLEAN MODE).
      This is a case that demonstrates a more general problem of parts of the query being
      moved to another level. When doing such transformation late in the optimization run
      when most of the flags about the contents of the query are already aggregated it's possible 
      to "split" the flags so that they correctly reflect the new queries after the transformation.
      In specific the ST_SELECT_LEX::ftfunc_list is holding all the free text function for all the 
      parts of the second SELECT in the UNION and we don't know what part of that is in the ORDER BY
      that we're to move to the UNION level and what part is about the other parts of the second SELECT.
      Fixed by throwing and error when such statements are about to be processed by adding a check 
      for the presence of MATCH() inside the ORDER BY clause that's going to get promoted to UNION.
      To workaround this new limitation one must parenthesize the UNION SELECTs and provide a real 
      global ORDER BY for the UNION outside of the parenthesis.
      83437f46
    • Ramil Kalimullin's avatar
      Fix for bug#49570: Assertion failed: !(order->used & map) · 6bc9c950
      Ramil Kalimullin authored
      on re-execution of prepared statement
      
      Problem: some (see eq_ref_table()) ORDER BY/GROUP BY optimization
      is called before each PS execution. However, we don't properly 
      initialize its stucture every time before the call.
      
      Fix: properly initialize the sturture used.
      
      
      
      mysql-test/r/ps.result:
        Fix for bug#49570: Assertion failed: !(order->used & map) 
        on re-execution of prepared statement
          - test result.
      mysql-test/t/ps.test:
        Fix for bug#49570: Assertion failed: !(order->used & map) 
        on re-execution of prepared statement
          - test case.
      sql/sql_select.cc:
        Fix for bug#49570: Assertion failed: !(order->used & map) 
        on re-execution of prepared statement
          - set order->used to 0 before each eq_ref_table() call,
        as the function relies on that.
      6bc9c950
  3. 17 Dec, 2009 1 commit
    • Martin Hansson's avatar
      Bug#47650: using group by with rollup without indexes · 16ed8699
      Martin Hansson authored
      returns incorrect results with where
      
      An outer join of a const table (outer) and a normal table
      (inner) with GROUP BY on a field from the outer table would
      optimize away GROUP BY, and thus trigger the optimization to
      do away with a temporary table if grouping was performed on
      columns from the const table, hence executing the query with
      filesort without temporary table. But this should not be
      done if there is a non-indexed access to the inner table,
      since filesort does not handle joins. It expects either ref
      access, range ditto or table scan. The join condition will
      thus not be applied.
      
      Fixed by always forcing execution with temporary table in
      the case of ROLLUP with a query involving an outer join. This
      is a slightly broader class of queries than need fixing, but
      it is hard to ascertain the position of a ROLLUP field wrt
      outer join with current query representation.
      
      mysql-test/r/join_outer.result:
        Bug#47650: Test result
      mysql-test/t/join_outer.test:
        Bug#47650: Test case
      sql/sql_select.cc:
        Bug#47650: Fix
      16ed8699
  4. 15 Dec, 2009 2 commits
    • Georgi Kodinov's avatar
      Bug #48709: Assertion failed in sql_select.cc:11782: · 4a41e5b1
      Georgi Kodinov authored
       int join_read_key(JOIN_TAB*)
      
      The eq_ref access method TABLE_REF (accessed through 
      JOIN_TAB) to save state and to track if this is the 
      first row it finds or not.
      This state was not reset on subquery re-execution
      causing an assert.
      
      Fixed by resetting the state before the subquery 
      re-execution.
      4a41e5b1
    • Georgi Kodinov's avatar
      Bug #48709: Assertion failed in sql_select.cc:11782: · c94fdc7e
      Georgi Kodinov authored
       int join_read_key(JOIN_TAB*)
      
      The eq_ref access method TABLE_REF (accessed through 
      JOIN_TAB) to save state and to track if this is the 
      first row it finds or not.
      This state was not reset on subquery re-execution
      causing an assert.
      
      Fixed by resetting the state before the subquery 
      re-execution.
      c94fdc7e
  5. 09 Dec, 2009 1 commit
    • Olav Sandstaa's avatar
      Fix for Bug#49506 Valgrind error in make_cond_for_table_from_pred · ee788174
      Olav Sandstaa authored
            
      This fix has been proposed by Sergey Petrunya and has been contributed
      under SCA by sca@askmonty.org.
            
      The cause for this valgrind error is that in the function
      add_cond_and_fix() in sql_select.cc an Item_cond_and object is
      created. This is marked as fixed but does not have a correct
      table_map() attribute. Later, in make_join_select(), if
      engine_condition_pushdown is in use, this table map is used and
      results in the valgrind error.
            
      The fix is to add a call to update_used_tables() in add_cond_and_fix()
      so that the table map is updated correctly.
            
      This patch is tested by multiple existing tests (e.g. the tests
      innodb_mysql, innodb, fulltext, compress all produces this valgrind
      warning/error without this fix).
      
      
      sql/sql_select.cc:
        In add_cond_and_fix() add a call to update_used_tables() to ensure
        the table map is updated.
      ee788174
  6. 07 Dec, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #42760: Select doesn't return desired results when we have null values · b19593a5
      Georgi Kodinov authored
      Part 2 : 
      There was a special optimization on the ref access method for 
      ORDER BY ... DESC that was set without actually looking on the type of the 
      selected index for ORDER BY.
      Fixed the SELECT ... ORDER BY .. DESC (it uses a different code path compared
      to the ASC that has been fixed with the previous fix).
      b19593a5
  7. 04 Dec, 2009 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug#49199: Optimizer handles incorrectly: · cb744ed9
      Ramil Kalimullin authored
      field='const1' AND field='const2' in some cases
      
      Building multiple equality predicates containing
      a constant which is compared as a datetime (with a field)
      we should take this fact into account and compare the 
      constant with another possible constatns as datetimes 
      as well.
      
      E.g. for the
      SELECT ... WHERE a='2001-01-01' AND a='2001-01-01 00:00:00'
      we should compare '2001-01-01' with '2001-01-01 00:00:00' as
      datetimes but not as strings.
      
      
      mysql-test/r/select.result:
        Fix for bug#49199: Optimizer handles incorrectly: 
        field='const1' AND field='const2' in some cases
          - test result.
      mysql-test/t/select.test:
        Fix for bug#49199: Optimizer handles incorrectly: 
        field='const1' AND field='const2' in some cases
          - test case.
      sql/item_cmpfunc.cc:
        Fix for bug#49199: Optimizer handles incorrectly: 
        field='const1' AND field='const2' in some cases
          - adding a constant to Item_equal compare it as
        a datetime value with stored one if there's a 
        date[time] field in a equality predicate.
      sql/item_cmpfunc.h:
        Fix for bug#49199: Optimizer handles incorrectly: 
        field='const1' AND field='const2' in some cases
          - adding a constant to Item_equal compare it as
        a datetime value with stored one if there's a 
        date[time] field in a equality predicate.
      sql/sql_select.cc:
        Fix for bug#49199: Optimizer handles incorrectly: 
        field='const1' AND field='const2' in some cases
          - adding a constant to Item_equal compare it as
        a datetime value with stored one if there's a 
        date[time] field in a equality predicate.
      cb744ed9
  8. 25 Nov, 2009 6 commits
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · 19738fdb
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 3190 [merge]
      > revision-id: kostja@sun.com-20091103174552-bfpak6r7ngf5cbjb
      > parent: magnus.blaudd@sun.com-20091103170719-6b64sjnivsiyz6xy
      > parent: kostja@sun.com-20091103165854-7di545xruez8w207
      > committer: Konstantin Osipov <kostja@sun.com>
      > branch nick: 5.1-41756
      > timestamp: Tue 2009-11-03 20:45:52 +0300
      > message:
      >   A fix and a test case for 
      >   Bug#41756 "Strange error messages about locks from InnoDB".
      >         
      >   In JT_EQ_REF (join_read_key()) access method, 
      >   don't try to unlock rows in the handler, unless certain that 
      >   a) they were locked
      >   b) they are not used.
      >   
      >   Unlocking of rows is done by the logic of the nested join loop,
      >   and is unaware of the possible caching that the access method may
      >   have. This could lead to double unlocking, when a row
      >   was unlocked first after reading into the cache, and then 
      >   when taken from cache, as well as to unlocking of rows which
      >   were actually used (but taken from cache).
      >         
      >   Delegate part of the unlocking logic to the access method,
      >   and in JT_EQ_REF count how many times a record was actually 
      >   used in the join. Unlock it only if it's usage count is 0.
      >   
      >   Implemented review comments.
      > ------------------------------------------------------------
      > Use --include-merges or -n0 to see merged revisions.
      19738fdb
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · cb19889a
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 3148.8.5
      > revision-id: davi.arnaut@sun.com-20091102112139-pztthzy6qj8jzomn
      > parent: svoj@sun.com-20091103091902-vwszwwpfi1f4zrpn
      > committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
      > branch nick: 48370-5.1
      > timestamp: Mon 2009-11-02 09:21:39 -0200
      > message:
      >   Bug#48370: Absolutely wrong calculations with GROUP BY and decimal fields when using IF
      >   Bug#45261: Crash, stored procedure + decimal
      >   
      >   Revert fix for Bug#45261 due to unforeseen bugs.
      cb19889a
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · 196d564a
      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.
      > ------------------------------------------------------------
      196d564a
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · 4b93aa6a
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 1810.3964.1
      > revision-id: alexey.kopytov@sun.com-20091030155453-0vlfwki805h9os62
      > parent: joerg@mysql.com-20091016122941-rf6z0keqvmlgjfto
      > committer: Alexey Kopytov <Alexey.Kopytov@Sun.com>
      > branch nick: my50-bug48131
      > timestamp: Fri 2009-10-30 18:54:53 +0300
      > message:
      >   Bug #48131: crash group by with rollup, distinct, filesort,
      >               with temporary tables
      >   
      >   There were two problems the test case from this bug was
      >   triggering:
      >   
      >   1. JOIN::rollup_init() was supposed to wrap all constant Items
      >   into another object for queries with the WITH ROLLUP modifier
      >   to ensure they are never considered as constants and therefore
      >   are written into temporary tables if the optimizer chooses to
      >   employ them for DISTINCT/GROUP BY handling.
      >   
      >   However, JOIN::rollup_init() was called before
      >   make_join_statistics(), so Items corresponding to fields in
      >   const tables could not be handled as intended, which was
      >   causing all kinds of problems later in the query execution. In
      >   particular, create_tmp_table() assumed all constant items
      >   except "hidden" ones to be removed earlier by remove_const()
      >   which led to improperly initialized Field objects for the
      >   temporary table being created. This is what was causing crashes
      >   and valgrind errors in storage engines.
      >   
      >   2. Even when the above problem had been fixed, the query from
      >   the test case produced incorrect results due to some
      >   DISTINCT/GROUP BY optimizations being performed by the
      >   optimizer that are inapplicable in the WITH ROLLUP case.
      >   
      >   Fixed by disabling inapplicable DISTINCT/GROUP BY optimizations
      >   when the WITH ROLLUP modifier is present, and splitting the
      >   const-wrapping part of JOIN::rollup_init() into a separate
      >   method which is now invoked after make_join_statistics() when
      >   the const tables are already known.
      4b93aa6a
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · c14bf1ca
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 1810.3961.6
      > revision-id: joro@sun.com-20091030094044-quadg0bwjy7cwqzw
      > parent: joro@sun.com-20091029152429-ks55fhrp4lhknyij
      > committer: Georgi Kodinov <joro@sun.com>
      > branch nick: B48293-5.0-bugteam
      > timestamp: Fri 2009-10-30 11:40:44 +0200
      > message:
      >   Bug #48293: crash with procedure analyse, view with > 10 columns,
      >   having clause...
      >   
      >   The fix for bug 46184 was not very complete. It was not covering
      >   views using temporary tables and multiple tables in a FROM clause.
      >   Fixed by reverting the fix for 46184 and making a more general
      >   check that is checking at the right execution stage and for all
      >   of the non-supported cases.
      >   Now PROCEDURE ANALYZE on non-top level SELECT is also forbidden.
      >   Updated the analyse.test and subselect.test accordingly.
      c14bf1ca
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · a58a5e32
      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.
      a58a5e32
  9. 20 Nov, 2009 2 commits
    • Kristofer Pettersson's avatar
      Bug#45613 handle failures from my_hash_insert · ea46fc4b
      Kristofer Pettersson authored
      Not all my_hash_insert() calls are checked for return value.
      
      This patch adds appropriate checks and failure responses
      where needed.
      
      
      mysys/hash.c:
        * Debug hook for testing failures in my_hash_insert()
      ea46fc4b
    • Georgi Kodinov's avatar
      Bug #45261 : Crash, stored procedure + decimal · c2c33491
      Georgi Kodinov authored
      Bug #48370  Absolutely wrong calculations with GROUP BY and
        decimal fields when using IF
      
      Added the test cases in the above two bugs for regression
      testing.
      Added additional tests that demonstrate a incomplete fix.
      Added a new factory method for Field_new_decimal to 
      create a field from an (decimal returning) Item.
      In the new method made sure that all the precision and 
      length variables are capped in a proper way. 
      This is required because Item's can have larger precision
      than the decimal fields and thus need to be capped when
      creating a field based on an Item type.
      Fixed the wrong typecast to Item_decimal.
      c2c33491
  10. 13 Nov, 2009 1 commit
    • Jorgen Loland's avatar
      Bug#48052: Valgrind warning - uninitialized value in · dc61ff1f
      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().
      
      
      mysql-test/r/select.result:
        Add test for BUG#48052
      mysql-test/t/select.test:
        Add test for BUG#48052
      sql/sql_select.cc:
        Properly initialize Item_cond_and by calling fix_fields (instead of quick_fix_field) when the Item that "ANDs" WHERE clause conditions with HAVING clause conditions is created.
      dc61ff1f
  11. 12 Nov, 2009 1 commit
  12. 09 Nov, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #48458: simple query tries to allocate enormous amount of · d4e4f95a
      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.
      d4e4f95a
  13. 10 Nov, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #42760: Select doesn't return desired results when we have null · b41d9093
      Georgi Kodinov authored
       values
       
       We should re-set the access method functions when changing the access
       method when switching to another index to avoid sorting.
       
       Fixed by doing a little re-engineering : encapsulating all the function
       assignment into a special function and calling it when flipping the 
       indexes.
      b41d9093
  14. 06 Nov, 2009 1 commit
    • Alexey Kopytov's avatar
      Bug #48475: DISTINCT is ignored with GROUP BY WITH ROLLUP and · 4bd2b0b0
      Alexey Kopytov authored
                  only const tables
      
      The problem was caused by two shortcuts in the optimizer that
      are inapplicable in the ROLLUP case.
      
      Normally in a case when only const tables are involved in a
      query, DISTINCT clause can be safely optimized away since there
      may be only one row produced by the join. Similarly, we don't
      need to create a temporary table to resolve DISTINCT/GROUP
      BY/ORDER BY. Both of these are inapplicable when the WITH
      ROLLUP modifier is present.
      
      Fixed by disabling the said optimizations for the WITH ROLLUP
      case.
      
      mysql-test/r/olap.result:
        Added a test case for bug #48475.
      mysql-test/t/olap.test:
        Added a test case for bug #48475.
      sql/sql_select.cc:
        Disabled const-only table optimizations for the WITH ROLLUP
        case.
      4bd2b0b0
  15. 03 Nov, 2009 1 commit
    • Konstantin Osipov's avatar
      A fix and a test case for · 37501b07
      Konstantin Osipov authored
      Bug#41756 "Strange error messages about locks from InnoDB".
      
      In JT_EQ_REF (join_read_key()) access method,
      don't try to unlock rows in the handler, unless certain that
      a) they were locked
      b) they are not used.
      
      Unlocking of rows is done by the logic of the nested join loop,
      and is unaware of the possible caching that the access method may
      have. This could lead to double unlocking, when a row
      was unlocked first after reading into the cache, and then
      when taken from cache, as well as to unlocking of rows which
      were actually used (but taken from cache).
      
      Delegate part of the unlocking logic to the access method,
      and in JT_EQ_REF count how many times a record was actually
      used in the join. Unlock it only if it's usage count is 0.
      
      Implemented review comments.
      
      
      mysql-test/r/bug41756.result:
        Add result file (Bug#41756)
      mysql-test/t/bug41756-master.opt:
        Use --innodb-locks-unsafe-for-binlog, as in 5.0 just
        using read_committed isolation is not sufficient to 
        reproduce the bug.
      mysql-test/t/bug41756.test:
        Add a test file (Bug#41756)
      sql/item_subselect.cc:
        Complete struct READ_RECORD initialization with a new
        member to unlock records.
      sql/records.cc:
        Extend READ_RECORD API with a method to unlock read records.
      sql/sql_select.cc:
        In JT_EQ_REF (join_read_key()) access method,
        don't try to unlock rows in the handler, unless certain that
        a) they were locked
        b) they are not used.
      sql/sql_select.h:
        Add members to TABLE_REF to count TABLE_REF buffer usage count.
      sql/structs.h:
        Update declarations.
      37501b07
  16. 02 Nov, 2009 1 commit
  17. 30 Oct, 2009 3 commits
    • Alexey Kopytov's avatar
      Bug #48131: crash group by with rollup, distinct, filesort, · bbca373e
      Alexey Kopytov authored
                  with temporary tables
      
      There were two problems the test case from this bug was
      triggering:
      
      1. JOIN::rollup_init() was supposed to wrap all constant Items
      into another object for queries with the WITH ROLLUP modifier
      to ensure they are never considered as constants and therefore
      are written into temporary tables if the optimizer chooses to
      employ them for DISTINCT/GROUP BY handling.
      
      However, JOIN::rollup_init() was called before
      make_join_statistics(), so Items corresponding to fields in
      const tables could not be handled as intended, which was
      causing all kinds of problems later in the query execution. In
      particular, create_tmp_table() assumed all constant items
      except "hidden" ones to be removed earlier by remove_const()
      which led to improperly initialized Field objects for the
      temporary table being created. This is what was causing crashes
      and valgrind errors in storage engines.
      
      2. Even when the above problem had been fixed, the query from
      the test case produced incorrect results due to some
      DISTINCT/GROUP BY optimizations being performed by the
      optimizer that are inapplicable in the WITH ROLLUP case.
      
      Fixed by disabling inapplicable DISTINCT/GROUP BY optimizations
      when the WITH ROLLUP modifier is present, and splitting the
      const-wrapping part of JOIN::rollup_init() into a separate
      method which is now invoked after make_join_statistics() when
      the const tables are already known.
      
      mysql-test/r/olap.result:
        Added a test case for bug #48131.
      mysql-test/t/olap.test:
        Added a test case for bug #48131.
      sql/sql_select.cc:
        1. Disabled inapplicable DISTINCT/GROUP BY optimizations when
        the WITH ROLLUP modifier is present.
        2. Split the const-wrapping part of JOIN::rollup_init() into a
        separate method.
      sql/sql_select.h:
        Added rollup_process_const_fields() declaration.
      bbca373e
    • Georgi Kodinov's avatar
      Bug #48291 : crash with row() operator,select into @var, and · 16d0f7f9
      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.
      16d0f7f9
    • Georgi Kodinov's avatar
      Bug #48293: crash with procedure analyse, view with > 10 columns, · fc80944c
      Georgi Kodinov authored
      having clause...
      
      The fix for bug 46184 was not very complete. It was not covering
      views using temporary tables and multiple tables in a FROM clause.
      Fixed by reverting the fix for 46184 and making a more general
      check that is checking at the right execution stage and for all
      of the non-supported cases.
      Now PROCEDURE ANALYZE on non-top level SELECT is also forbidden.
      Updated the analyse.test and subselect.test accordingly.
      fc80944c
  18. 29 Oct, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #42116 : Mysql crash on specific query · eb9a854d
      Georgi Kodinov authored
      Queries with nested outer joins may lead to crashes or 
      bad results because an internal data structure is not handled
      correctly.
      The optimizer uses bitmaps of nested JOINs to determine
      if certain table can be placed at a certain place in the
      JOIN order.
      It does maintain a bitmap describing in which JOINs 
      last placed table is nested.
      When it puts a table it makes sure the bit of every JOIN that
      contains the table in question is set (because JOINs can be nested).
      It does that by recursively setting the bit for the next enclosing
      JOIN when this is the first table in the JOIN and recursively 
      resetting the bit if it's the last table in the JOIN.
      When it removes a table from the join order it should do the
      opposite : recursively unset the bit if it's the only remaining 
      table in this join and and recursively set the bit if it's removing
      the last table of a JOIN.
      There was an error in how the bits was set for the upper levels :
      when removing a table it was setting the bit for all the enclosing 
      nested JOINs even if there were more tables left in the current JOIN
      (which practically means that the upper nested JOINs were not affected).
      Fixed by stopping the recursion at the relevant level.
      
      mysql-test/r/join.result:
        Bug #42116: test case
      mysql-test/t/join.test:
        Bug #42116: test case
      sql/sql_select.cc:
        Bug #41116: don't go up and set the bits if more tables in
        at the current JOIN level
      eb9a854d
  19. 21 Oct, 2009 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, · 5e3f89fd
      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.
      
      
      mysql-test/r/select.result:
        Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
        line 138 when forcing a spatial index
          - test result.
      mysql-test/t/select.test:
        Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
        line 138 when forcing a spatial index
          - test case.
      sql/sql_select.cc:
        Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
        line 138 when forcing a spatial index
          - disable spatial indexes for queries which use 
        non-spatial conditions (e.g. NATURAL JOINs).
      5e3f89fd
  20. 14 Oct, 2009 2 commits
    • Jorgen Loland's avatar
      Followup patch for BUG#47280 · 08965b75
      Jorgen Loland authored
      Temporary tables may set join->group to 0 even though there is 
      grouping. Also need to test if sum_func_count>0 when JOIN::exec() 
      decides whether to present results in a grouped manner.
      
      sql/sql_select.cc:
        Temporary tables may set join->group to 0 even though there is 
        grouping. Also need to test if sum_func_count>0 when JOIN::exec() 
        decides whether to present results in a grouped manner.
      08965b75
    • Jorgen Loland's avatar
      Bug#47280 - strange results from count(*) with order by multiple · 3ab5751a
      Jorgen Loland authored
                  columns without where/group
                           
      Simple SELECT with implicit grouping used to return many rows if
      the query was ordered by the aggregated column in the SELECT
      list. This was incorrect because queries with implicit grouping
      should only return a single record.
                                    
      The problem was that when JOIN:exec() decided if execution needed
      to handle grouping, it was assumed that sum_func_count==0 meant
      that there were no aggregate functions in the query. This
      assumption was not correct in JOIN::exec() because the aggregate
      functions might have been optimized away during JOIN::optimize().
                        
      The reason why queries without ordering behaved correctly was
      that sum_func_count is only recalculated if the optimizer chooses
      to use temporary tables (which it does in the ordered case).
      Hence, non-ordered queries were correctly treated as grouped.
                        
      The fix for this bug was to remove the assumption that
      sum_func_count==0 means that there is no need for grouping. This
      was done by introducing variable "bool implicit_grouping" in the
      JOIN object.
      
      mysql-test/r/func_group.result:
        Add test for BUG#47280
      mysql-test/t/func_group.test:
        Add test for BUG#47280
      sql/opt_sum.cc:
        Improve comment for opt_sum_query()
      sql/sql_class.h:
        Add comment for variables in TMP_TABLE_PARAM
      sql/sql_select.cc:
        Introduce and use variable implicit_grouping instead of (!group_list && sum_func_count) in places that need to test if grouping is required. Also added comments for: optimization of aggregate fields for implicitly grouped queries  (JOIN::optimize) and choice of end_select method (JOIN::execute)
      sql/sql_select.h:
        Add variable implicit_grouping, which will be TRUE for queries that contain aggregate functions but no GROUP BY clause. Also added comment to sort_and_group variable.
      3ab5751a
  21. 07 Oct, 2009 1 commit
  22. 30 Sep, 2009 1 commit
    • MySQL Build Team's avatar
      Backport into build-200909301147-5.0.84sp1 · eb488ba6
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 2791.2.3
      > revision-id: joro@sun.com-20090827114042-h55n7qp9990bl6ge
      > parent: anurag.shekhar@sun.com-20090831073231-e55y1hsck6n08ux8
      > committer: Georgi Kodinov <joro@sun.com>
      > branch nick: B46749-5.0-bugteam
      > timestamp: Thu 2009-08-27 14:40:42 +0300
      > message:
      >   Bug #46749: Segfault in add_key_fields() with outer subquery level 
      >     field references
      >   
      >   This error requires a combination of factors : 
      >   1. An "impossible where" in the outermost SELECT
      >   2. An aggregate in the outermost SELECT
      >   3. A correlated subquery with a WHERE clause that includes an outer 
      >   field reference as a top level WHERE sargable predicate
      >   
      >   When JOIN::optimize detects an "impossible WHERE" it will bail out
      >   without doing the rest of the work and initializations. It will not
      >   call make_join_statistics() as well.  And make_join_statistics fills 
      >   in various structures for each table referenced.
      >   When processing the result of the "impossible WHERE" the query must
      >   send a single row of data if there are aggregate functions in it.
      >   In this case the server marks all the aggregates as having received 
      >   no rows and calls the relevant Item::val_xxx() method on the SELECT
      >   list. However if this SELECT list happens to contain a correlated 
      >   subquery this subquery is evaluated in a normal evaluation mode.
      >   And if this correlated subquery has a reference to a field from the 
      >   outermost "impossible where" SELECT the add_key_fields will mistakenly
      >   consider the outer field reference as a "local" field reference when 
      >   looking for sargable predicates.
      >   But since the SELECT where the outer field reference refers to is not
      >   completely initialized due to the "impossible WHERE" in this level
      >   we'll get a NULL pointer reference.
      >   Fixed by making a better condition for discovering if a field is "local"
      >   to the SELECT level being processed. 
      >   It's not enough to look for OUTER_REF_TABLE_BIT in this case since 
      >   for outer references to constant tables the Item_field::used_tables() 
      >   will return 0 regardless of whether the field reference is from the 
      >   local SELECT or not.
      eb488ba6
  23. 23 Sep, 2009 1 commit
  24. 22 Sep, 2009 2 commits
    • MySQL Build Team's avatar
      Backport into build-200909221805-5.1.37sp1 · 460c6c97
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 3092.1.2 [merge]
      > revision-id: joro@sun.com-20090831134035-wndnw04gy8kzogpm
      > parent: anurag.shekhar@sun.com-20090831075609-tkpqu41hxtupdeip
      > parent: joro@sun.com-20090827114042-h55n7qp9990bl6ge
      > committer: Georgi Kodinov <joro@sun.com>
      > branch nick: B46749-5.1-bugteam
      > timestamp: Mon 2009-08-31 16:40:35 +0300
      > message:
      >   automerge
      > ------------------------------------------------------------
      > Use --include-merges or -n0 to see merged revisions.
      460c6c97
    • MySQL Build Team's avatar
      Backport into build-200909221805-5.1.37sp1 · 4f1bd338
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 3059 [merge]
      > revision-id: martin.hansson@sun.com-20090810140851-aw5peehzdxi4gjja
      > parent: iggy@mysql.com-20090806145453-ion37sfdsldwwjrj
      > parent: martin.hansson@sun.com-20090807115140-7fn6wjx0mrui7zl5
      > committer: Martin Hansson <martin.hansson@sun.com>
      > branch nick: 5.1bt
      > timestamp: Mon 2009-08-10 16:08:51 +0200
      > message:
      >   Merge
      > ------------------------------------------------------------
      > Use --include-merges or -n0 to see merged revisions.
      4f1bd338
  25. 18 Sep, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #47106: Crash / segfault on adding EXPLAIN to a non-crashing · 2e5b0828
      Georgi Kodinov authored
       query
            
      The fix for bug 46749 removed the check for OUTER_REF_TABLE_BIT 
      and substituted it for a check on the presence of 
      Item_ident::depended_from.
      Removing it altogether was wrong : OUTER_REF_TABLE_BIT should 
      still be checked in addition to depended_from (because it's not 
      set in all cases and doesn't contradict to the check of depended_from).
      Fixed by returning the old condition back as a compliment to the 
      new one.
      2e5b0828
  26. 17 Sep, 2009 1 commit
  27. 05 Sep, 2009 1 commit
    • Alexey Kopytov's avatar
      Bug #46159: simple query that never returns · 7def660a
      Alexey Kopytov authored
       
      The external 'for' loop in remove_dup_with_compare() handled 
      HA_ERR_RECORD_DELETED by just starting over without advancing 
      to the next record which caused an infinite loop. 
       
      This condition could be triggered on certain data by a SELECT 
      query containing DISTINCT, GROUP BY and HAVING clauses. 
      
      Fixed remove_dup_with_compare() so that we always advance to 
      the next record when receiving HA_ERR_RECORD_DELETED from 
      rnd_next(). 
      
      mysql-test/r/distinct.result:
        Added a test case for bug #46159.
      mysql-test/t/distinct.test:
        Added a test case for bug #46159.
      sql/sql_select.cc:
        Fixed remove_dup_with_compare() so that we always advance to 
        the next record when receiving HA_ERR_RECORD_DELETED from 
        rnd_next().
      7def660a
  28. 04 Sep, 2009 1 commit
    • Sergey Glukhov's avatar
      Bug#45989 memory leak after explain encounters an error in the query · faf5044d
      Sergey Glukhov authored
      Memory allocated in TMP_TABLE_PARAM::copy_field is not cleaned up.
      The fix is to clean up TMP_TABLE_PARAM::copy_field array in JOIN::destroy.
      
      
      mysql-test/r/explain.result:
        test result
      mysql-test/t/explain.test:
        test case
      sql/sql_select.cc:
        Memory allocated in TMP_TABLE_PARAM::copy_field is not cleaned up.
        The fix is to clean up TMP_TABLE_PARAM::copy_field array in JOIN::destroy.
      faf5044d