An error occurred fetching the project authors.
- 10 Oct, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
statement. The problem was that during statement re-execution if the result was empty the old result could be returned for group functions. The solution is to implement proper cleanup() method in group functions.
-
- 16 Sep, 2006 1 commit
-
-
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.
-
- 06 Jul, 2006 1 commit
-
-
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.
-
- 07 Apr, 2006 2 commits
-
-
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.
-
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.
-
- 23 Feb, 2006 1 commit
-
-
konstantin@mysql.com authored
fixed in 5.0). A post-review fix (Bug#13134)
-
- 21 Feb, 2006 1 commit
-
-
konstantin@mysql.com authored
column is increasing when table is recreated with PS/SP": make use of create_field::char_length more consistent in the code. Reinit create_field::length from create_field::char_length for every execution of a prepared statement (actually fixes the bug).
-
- 16 Jan, 2006 1 commit
-
-
konstantin@mysql.com authored
-
- 14 Jan, 2006 1 commit
-
-
konstantin@mysql.com authored
return incorrect result set for a select SQL request"
-
- 25 Nov, 2005 1 commit
-
-
konstantin@mysql.com authored
CREATE TABLE and PS/SP": make sure that 'typelib' object for ENUM values and 'Item_string' object for DEFAULT clause are created in the statement memory root.
-
- 06 Sep, 2005 1 commit
-
-
gluh@eagle.intranet.mysql.r18.ru authored
Argument of RAND function can be constant value only
-
- 15 Jul, 2005 1 commit
-
-
konstantin@mysql.com authored
of system vars at PREPARE time": implement a special Item to handle system variables. This item substitutes itself with a basic constant containing variable value at fix_fields.
-
- 14 Jul, 2005 1 commit
-
-
konstantin@mysql.com authored
syntax in binlog which stops replication": disallow the use of parameter markers which can lead to generation of malformed binlog queries.
-
- 13 Jul, 2005 4 commits
-
-
konstantin@mysql.com authored
character set is UCS2". The bug is no longer repeatable.
-
konstantin@mysql.com authored
binary).
-
konstantin@mysql.com authored
-
konstantin@mysql.com authored
data": remove the fix for another bug (8807) that added OUTER_REF_TABLE_BIT to all subqueries that used a placeholder to prevent their evaluation at prepare. As this bit hanged in Item_subselect::used_tables_cache for ever, a constant subquery with a placeholder was never evaluated as such, which caused wrong choice of the execution plan for the statement. - to fix Bug#8807 backport a better fix from 5.0 - post-review fixes.
-
- 20 Jun, 2005 1 commit
-
-
dlenev@brandersnatch.localdomain authored
INSERT ... SELECT with UNION" (reviewed version). Altough bug manifest itself only starting from 5.0 it is better to apply fix to 4.1 to keep some assumptions true and make code more future-proof.
-
- 05 May, 2005 1 commit
-
-
konstantin@mysql.com authored
should return a non empty one" (see comments for the changed files for details).
-
- 03 May, 2005 1 commit
-
-
konstantin@mysql.com authored
records if prepared statements is used". This fix changes equality evaluation method of basic constants from by-name to by-value, thus effectively enabling use of parameter markers in some optimizations (constants propagation, evaluation of possible keys for query).
-
- 02 Mar, 2005 1 commit
-
-
ramil@mysql.com authored
-
- 08 Dec, 2004 1 commit
-
-
konstantin@mysql.com authored
during execute"
-
- 21 Nov, 2004 1 commit
-
-
konstantin@mysql.com authored
of <parameter> IS NULL": we must not only set Item::null_value in Item_param, but implement Item_param::is_null() to work well with IS NULL/IS NOT NULL clauses.
-
- 05 Nov, 2004 1 commit
-
-
bar@mysql.com authored
Bug #6351 make test failure "Unknown character set" UCS2 related tests were moved into ctype_ucs.
-
- 27 Oct, 2004 1 commit
-
-
ram@gw.mysql.r18.ru authored
-
- 23 Oct, 2004 1 commit
-
-
monty@mysql.com authored
Fixed wrong range test code for HEAP tables. This caused a crash when doing a range test with a key that didn't have lower or upper bound (Bug #6082) More test cases
-
- 22 Oct, 2004 4 commits
-
-
konstantin@mysql.com authored
-
konstantin@mysql.com authored
prepared statements when LIMIT is used" and post-review comments. The fix changes the approach we calculate the need for ORDER BY in UNION: the previous was not PS friendly, as it damaged SELECT_LEX options in case of single select.
-
monty@mysql.com authored
Fixed checking of privilege handling in CREATE ... SELECT (Bug #6094)
-
konstantin@mysql.com authored
names with ident. tables fr. diff. schemata": revise all uses of Item_field and make them prepared-statements friendly when necessary.
-
- 13 Oct, 2004 1 commit
-
-
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.
-
- 12 Oct, 2004 1 commit
-
-
konstantin@mysql.com authored
propogation works only once (prepared statements)".
-
- 09 Oct, 2004 1 commit
-
-
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.
-
- 07 Oct, 2004 1 commit
-
-
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.
-
- 23 Sep, 2004 1 commit
-
-
konstantin@mysql.com authored
-
- 17 Sep, 2004 1 commit
-
-
konstantin@mysql.com authored
key Column Fails".
-
- 03 Sep, 2004 1 commit
-
-
konstantin@mysql.com authored
server': the bug occurs when arguments of LIKE function are in differentcharacter sets. If these character sets are compatible, we create an item-converter. In prepared mode, this item needs to be created in memory of current prepared statement.
-
- 29 Aug, 2004 1 commit
-
-
sergefp@mysql.com authored
-
- 24 Aug, 2004 1 commit
-
-
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.
-
- 20 Aug, 2004 1 commit
-
-
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.
-