An error occurred fetching the project authors.
  1. 10 Oct, 2006 1 commit
  2. 16 Sep, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #22085: Crash on the execution of a prepared · dd3b8e4f
      igor@rurik.mysql.com authored
      statement that uses an aggregating IN subquery with 
      HAVING clause.
      A wrong order of the call of split_sum_func2 for the HAVING
      clause of the subquery and the transformation for the 
      subquery resulted in the creation of a andor structure
      that could not be restored at an execution of the prepared
      statement.
      dd3b8e4f
  3. 06 Jul, 2006 1 commit
    • konstantin@bodhi.netgear's avatar
      A fix and a test case for Bug#19399 "res 'Lost Connection' when · 8e735d2c
      konstantin@bodhi.netgear authored
      dropping/creating tables".
      
      The bug could lead to a crash when multi-delete statements were
      prepared and used with temporary tables.
      
      The bug was caused by lack of clean-up of multi-delete tables before
      re-execution of a prepared statement. In a statement like
      DELETE t1 FROM t1, t2 WHERE ... the first table list (t1) is
      moved to lex->auxilliary_table_list and excluded from lex->query_tables
      or select_lex->tables. Thus it was unaccessible to reinit_stmt_before_use
      and not cleaned up before re-execution of a prepared statement. 
      8e735d2c
  4. 07 Apr, 2006 2 commits
    • konstantin@mysql.com's avatar
      A fix and a test case for Bug#16365 "Prepared Statements: DoS with · 51899331
      konstantin@mysql.com authored
      too many open statements". The patch adds a new global variable
      @@max_prepared_stmt_count. This variable limits the total number
      of prepared statements in the server. The default value of
      @@max_prepared_stmt_count is 16382. 16382 small statements
      (a select against 3 tables with GROUP, ORDER and LIMIT) consume 
      100MB of RAM. Once this limit has been reached, the server will 
      refuse to prepare a new statement and return ER_UNKNOWN_ERROR 
      (unfortunately, we can't add new errors to 4.1 without breaking 5.0). The limit is changeable after startup
      and can accept any value from 0 to 1 million. In case
      the new value of the limit is less than the current
      statement count, no new statements can be added, while the old
      still can be used. Additionally, the current count of prepared 
      statements is now available through a global read-only variable 
      @@prepared_stmt_count.
      51899331
    • konstantin@mysql.com's avatar
      A fix and a test case for Bug#16248 "WHERE (col1,col2) IN ((?,?)) · 15b59156
      konstantin@mysql.com authored
      gives wrong results". Implement previously missing 
      Item_row::cleanup. The bug is not repeatable in 5.0, probably 
      due to a coincidence: the problem is present in 5.0 as well.
      15b59156
  5. 23 Feb, 2006 1 commit
  6. 21 Feb, 2006 1 commit
  7. 16 Jan, 2006 1 commit
  8. 14 Jan, 2006 1 commit
  9. 25 Nov, 2005 1 commit
  10. 06 Sep, 2005 1 commit
  11. 15 Jul, 2005 1 commit
  12. 14 Jul, 2005 1 commit
  13. 13 Jul, 2005 4 commits
  14. 20 Jun, 2005 1 commit
  15. 05 May, 2005 1 commit
  16. 03 May, 2005 1 commit
  17. 02 Mar, 2005 1 commit
  18. 08 Dec, 2004 1 commit
  19. 21 Nov, 2004 1 commit
  20. 05 Nov, 2004 1 commit
  21. 27 Oct, 2004 1 commit
  22. 23 Oct, 2004 1 commit
  23. 22 Oct, 2004 4 commits
  24. 13 Oct, 2004 1 commit
    • konstantin@mysql.com's avatar
      A fix and test case for Bug#5985 ""prepare stmt from "select rand(?)" · 5abc3de2
      konstantin@mysql.com authored
      crashes server." The fix makes Item_func_rand prepared-statements
      aware plus it fixes the case when RAND is used in prepared
      statements and replication is on (as well as several similar issues).
      Until now we did not reset THD before every execution of a prepared
      statement, so if some execution had set thd->time_zone_used
      or thd->rand_used they would not be reset until next mysql_parse.
      Some of post-review fixes done.
      5abc3de2
  25. 12 Oct, 2004 1 commit
  26. 09 Oct, 2004 1 commit
    • konstantin@mysql.com's avatar
      A fix and test case for Bug#5987 "subselect in bool function · daa4c249
      konstantin@mysql.com authored
      crashes server (prepared statements)": the bug was that all boolean
      items always recovered its original arguments at statement cleanup 
      stage.
      This collided with Item_subselect::select_transformer, which tries to 
      permanently change the item tree to use a transformed subselect instead of
      original one.
      So we had this call sequence for prepare:
      mysql_stmt_prepare -> JOIN::prepare -> 
      Item_subselect::fix_fields -> the item tree gets transformed ->
      Item_bool_rowready_func2::cleanup, item tree is recovered to original
      state, while it shouldn't have been;
      mysql_stmt_execute -> attempts to execute a broken tree -> crash.
      Now instead of bluntly recovering all arguments of bool functions in 
      Item_bool_rowready_func2::cleanup, we recover only those
      which were changed, and do it in one place.
      There still would exist a possibility for a collision with subselect
      tranformation, if permanent and temporary changes were performed at the 
      same stage.
      But fortunately subselect transformation is always done first, so it 
      doesn't conflict with the optimization done by propogate_cond_constants.
      Now we have: 
      mysql_stmt_prepare -> JOIN::prepare -> subselect transformation 
      permanently changes the tree -> cleanup doesn't recover anything, 
      because nothing was registered for recovery.
      mysql_stmt_execute -> JOIN::prepare (the tree is already transformed, 
      so it doesn't change), JOIN::optimize -> 
      propogate_cond_constants -> temporary changes the item tree 
      with constants -> JOIN::execute -> cleanup -> 
      the changes done by propogate_cond_constants are recovered, as
      they were registered for recovery.
      daa4c249
  27. 07 Oct, 2004 1 commit
    • konstantin@mysql.com's avatar
      A fix for Bug#5748 "Prepared statement with BETWEEN and bigint values · 2aa7ec0d
      konstantin@mysql.com authored
      crashes mysqld": implementation for a generic item tree modifications
      registry. Every item tree modification which should be rolled back for
      subsequent execution of a prepared statement or stored procedure should
      be saved in the registry. All such modifications are rolled back at once
      during cleanup stage of PS.
      Actual fix for the bug just adds a call to register modifications to
      convert_constant_item.
      Post review fixes implemented.
      2aa7ec0d
  28. 23 Sep, 2004 1 commit
  29. 17 Sep, 2004 1 commit
  30. 03 Sep, 2004 1 commit
  31. 29 Aug, 2004 1 commit
  32. 24 Aug, 2004 1 commit
    • konstantin@mysql.com's avatar
      Fix for Bug#5034 "prepared "select 1 into @arg15", second · ae18dc3e
      konstantin@mysql.com authored
      execute crashes server": we were deleting lex->result
      after each execute, but prepared statements assumed that
      it's left intact.
      The fix adds cleanup() method to select_result hierarchy,
      so that result objects can be reused.
      Plus we now need to delete result objects more wisely.
      ae18dc3e
  33. 20 Aug, 2004 1 commit
    • konstantin@mysql.com's avatar
      Fix for bug#4912 "mysqld crashs in case a statement is executed · 568c6e85
      konstantin@mysql.com authored
       a second time". The bug was caused by incompatibility of
      negations elimination algorithm and PS: during first statement 
      execute a subtree with negation was replaced with equivalent 
      subtree without NOTs.
      The problem was that although this transformation was permanent, 
      items of the new subtree were created in execute-local memory.
      The patch adds means to check if it is the first execute of a
      prepared statement, and if this is the case, to allocate items
      in memory of the prepared statement.
      The implementation:
      - backports Item_arena from 5.0
      - adds Item_arena::is_stmt_prepare(), 
        Item_arena::is_first_stmt_execute().
      - deletes THD::allocate_temporary_pool_for_ps_preparing(),
        THD::free_temporary_pool_for_ps_preparing(); they
        were redundant.
      and adds a few invariants:
      - thd->free_list never contains junk (= freed items)
      - thd->current_arena is never null. If there is no
        prepared statement, it points at the thd. 
      The rest of the patch contains mainly mechanical changes and
      cleanups.
      568c6e85