An error occurred fetching the project authors.
- 19 Oct, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
When statement to be prepared contained CREATE PROCEDURE, CREATE FUNCTION or CREATE TRIGGER statements with a syntax error in it, the preparation would fail with syntax error message, but the memory could be corrupted. The problem occurred because we switch memroot when parse stored routine or trigger definitions, and on parse error we restored the original memroot only after performing some memory operations. In more detail: - prepared statement would activate its own memory root to parse the definition of the stored procedure. - SP would reset this memory root with its own memory root to parse SP statements - a syntax error would happen - prepared statement would restore the original memory root - stored procedure would restore what it thinks was the original memory root, but actually was the statement memory root. That led to double free - in destruction of the statement and in a next call to mysql_parse(). The solution is to restore memroot right after the failed parsing.
-
- 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.
-
- 27 Sep, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
Re-execution of a parametrized prepared statement or a stored routine with a SELECT that use LEFT JOIN with second table having only one row could yield incorrect result. The problem appeared only for left joins with second table having only one row (aka const table) and equation conditions in ON or WHERE clauses that depend on the argument passed. Once the condition was false for second const table, a NULL row was created for it, and any field involved got NULL-value flag, which then was never reset. The cause of the problem was that Item_field::null_value could be set without being reset for re-execution. The solution is to reset Item_field::null_value in Item_field::cleanup().
-
- 19 Sep, 2006 1 commit
-
-
igor@rurik.mysql.com authored
-
- 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.
-
- 24 Aug, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
Changes in an item tree done by optimizer weren't properly registered and went unnoticed, which resulted in preliminary freeing of used memory.
-
- 11 Jul, 2006 1 commit
-
-
kostja@bodhi.local authored
when dropping/creating tables"
-
- 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.
-
- 26 Jun, 2006 1 commit
-
-
konstantin@mysql.com authored
Bug#19022 "Memory bug when switching db during trigger execution" Bug#17199 "Problem when view calls function from another database." Bug#18444 "Fully qualified stored function names don't work correctly in SELECT statements" Documentation note: this patch introduces a change in behaviour of prepared statements. This patch adds a few new invariants with regard to how THD::db should be used. These invariants should be preserved in future: - one should never refer to THD::db by pointer and always make a deep copy (strmake, strdup) - one should never compare two databases by pointer, but use strncmp or my_strncasecmp - TABLE_LIST object table->db should be always initialized in the parser or by creator of the object. For prepared statements it means that if the current database is changed after a statement is prepared, the database that was current at prepare remains active. This also means that you can not prepare a statement that implicitly refers to the current database if the latter is not set. This is not documented, and therefore needs documentation. This is NOT a change in behavior for almost all SQL statements except: - ALTER TABLE t1 RENAME t2 - OPTIMIZE TABLE t1 - ANALYZE TABLE t1 - TRUNCATE TABLE t1 -- until this patch t1 or t2 could be evaluated at the first execution of prepared statement. CURRENT_DATABASE() still works OK and is evaluated at every execution of prepared statement. Note, that in stored routines this is not an issue as the default database is the database of the stored procedure and "use" statement is prohibited in stored routines. This patch makes obsolete the use of check_db_used (it was never used in the old code too) and all other places that check for table->db and assign it from THD::db if it's NULL, except the parser. How this patch was created: THD::{db,db_length} were replaced with a LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were manually checked and: - if the place uses thd->db by pointer, it was fixed to make a deep copy - if a place compared two db pointers, it was fixed to compare them by value (via strcmp/my_strcasecmp, whatever was approproate) Then this intermediate patch was used to write a smaller patch that does the same thing but without a rename. TODO in 5.1: - remove check_db_used - deploy THD::set_db in mysql_change_db See also comments to individual files.
-
- 29 May, 2006 1 commit
-
-
msvensson@shellback.(none) authored
-
- 25 Apr, 2006 1 commit
-
-
konstantin@mysql.com authored
supported in SP but not in PS": just enable them in prepared statements, the supporting functionality was implemented when they were enabled in stored procedures.
-
- 12 Apr, 2006 1 commit
-
-
konstantin@mysql.com authored
limit.
-
- 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.
-
- 28 Mar, 2006 1 commit
-
-
pem@mysql.com authored
-
- 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.
-
- 23 Nov, 2005 1 commit
-
-
jimw@mysql.com authored
-
- 08 Sep, 2005 1 commit
-
-
andrey@lmy004. authored
are thus dangling later)
-
- 06 Sep, 2005 1 commit
-
-
gluh@eagle.intranet.mysql.r18.ru authored
Argument of RAND function can be constant value only
-
- 28 Jul, 2005 1 commit
-
-
monty@mysql.com authored
-
- 15 Jul, 2005 2 commits
-
-
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.
-
tomas@poseidon.ndb.mysql.com authored
-
- 14 Jul, 2005 3 commits
-
-
konstantin@mysql.com authored
-
konstantin@mysql.com authored
-
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 2 commits
-
-
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.
-
msvensson@neptunus.(none) authored
- Print warning that says display width is not supported for datatype TIMESTAMP, if user tries to create a TIMESTAMP column with display width. - Use display width for TIMESTAMP only in type_timestamp test to make sure warning is displayed correctly.
-
- 07 Jun, 2005 1 commit
-
-
konstantin@mysql.com authored
error for LIMIT placeholder". The patch adds grammar support for LIMIT ?, ? and changes the type of ST_SELECT_LEX::select_limit,offset_limit from ha_rows to Item*, so that it can point to Item_param.
-
- 16 May, 2005 1 commit
-
-
monty@mysql.com authored
Fixed bug in mysql_stmt_fetch() when retrieving rows to return
-
- 05 May, 2005 2 commits
-
-
konstantin@mysql.com authored
-
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).
-