An error occurred fetching the project authors.
- 03 Feb, 2010 1 commit
-
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.12 > 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.
-
- 30 Sep, 2009 1 commit
-
-
Kristofer Pettersson authored
'flush tables' crashes The server crashes when 'show procedure status' and 'flush tables' are run concurrently. This is caused by the way mysql.proc table is added twice to the list of table to lock although the requirements on the current locking API assumes differently. No test case is submitted because of the nature of the crash which is currently difficult to reproduce in a deterministic way. This is a backport from 5.1
-
- 29 Sep, 2009 1 commit
-
-
Kristofer Pettersson authored
replication MySQL server uses wrong lock type (always TL_READ instead of TL_READ_NO_INSERT when appropriate) for tables used in subqueries of UPDATE statement. This leads in some cases to a broken replication as statements are written in the wrong order to the binlog.
-
- 27 Aug, 2009 1 commit
-
-
Sergey Glukhov authored
The crash happens because select_union object is used as result set for queries which have derived tables. select_union use temporary table as data storage and if fields count exceeds 10(count of values for procedure ANALYSE()) then we get a crash on fill_record() function.
-
- 16 Jul, 2009 1 commit
-
-
Georgi Kodinov authored
Fixed various compilation warnings when compiling on a 64 bit windows.
-
- 15 Jul, 2009 1 commit
-
-
Georgi Kodinov authored
Fixed the following problems: 1. cmake 2.6 warning because of a changed default on how the dependencies to libraries with a specified path are resolved. Fixed by requiring cmake 2.6. 2. Removed an obsolete pre-NT4 hack including defining Windows system defines to alter the behavior of windows.h. 3. Disabled warning C4065 on compiling sql_yacc.cc because of a know incompatibility in some of the newer bison binaries.
-
- 17 Jun, 2009 1 commit
-
-
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 second patch, fixing more of the warnings.
-
- 27 May, 2009 1 commit
-
-
Alexey Kopytov authored
old_password() functions The PASSWORD() and OLD_PASSWORD() functions could lead to memory reads outside of an internal buffer when used with BLOB arguments. String::c_ptr() assumes there is at least one extra byte in the internally allocated buffer when adding the trailing '\0'. This, however, may not be the case when a String object was initialized with externally allocated buffer. The bug was fixed by adding an additional "length" argument to make_scrambled_password_323() and make_scrambled_password() in order to avoid String::c_ptr() calls for PASSWORD()/OLD_PASSWORD(). However, since the make_scrambled_password[_323] functions are a part of the client library ABI, the functions with the new interfaces were implemented with the 'my_' prefix in their names, with the old functions changed to be wrappers around the new ones to maintain interface compatibility.
-
- 03 Apr, 2009 1 commit
-
-
Davi Arnaut authored
The problem is that a SELECT .. FOR UPDATE statement might open a table and later wait for a impeding global read lock without noticing whether it is holding a table that is being waited upon the the flush phase of the process that took the global read lock. The same problem also affected the following statements: LOCK TABLES .. WRITE UPDATE .. SET (update and multi-table update) TRUNCATE TABLE .. LOAD DATA .. The solution is to make the above statements wait for a impending global read lock before opening the tables. If there is no impending global read lock, the statement raises a temporary protection against global read locks and progresses smoothly towards completion. Important notice: the patch does not try to address all possible cases, only those which are common and can be fixed unintrusively enough for 5.0.
-
- 12 Feb, 2009 1 commit
-
-
Georgi Kodinov authored
Additional fix: 1. Revert the unification of DROP FUNCTION and DROP PROCEDURE, because DROP FUNCTION can be used to drop UDFs (that have a non-qualified name and don't require database name to be present and valid). 2. Fixed the case sensitivity problem by adding a call to check_db_name() (similar to the sp_name production).
-
- 10 Feb, 2009 1 commit
-
-
Georgi Kodinov authored
The parser was not using the correct fully-qualified-name production for DROP FUNCTION. Fixed by copying the production from DROP PROCEDURE. Tested in the windows specific suite to make sure it's tested on a case-insensitive file system.
-
- 21 Nov, 2008 1 commit
-
-
Alexey Botchkov authored
memory allocation error checks added for functions calling insert_dynamic() per-file messages: myisam/mi_delete.c Bug#25058 ignored return codes in memory allocation functions out-of-memory errors handled myisam/mi_write.c Bug#25058 ignored return codes in memory allocation functions out-of-memory errors handled server-tools/instance-manager/instance_options.cc Bug#25058 ignored return codes in memory allocation functions out-of-memory errors handled sql/slave.cc Bug#25058 ignored return codes in memory allocation functions out-of-memory errors handled sql/sp_head.cc Bug#25058 ignored return codes in memory allocation functions out-of-memory errors handled sql/sp_head.h Bug#25058 ignored return codes in memory allocation functions out-of-memory errors handled sql/sp_pcontext.cc Bug#25058 ignored return codes in memory allocation functions out-of-memory errors handled sql/sp_pcontext.h Bug#25058 ignored return codes in memory allocation functions out-of-memory errors handled sql/sql_select.cc Bug#25058 ignored return codes in memory allocation functions out-of-memory errors handled sql/sql_yacc.yy Bug#25058 ignored return codes in memory allocation functions out-of-memory errors handled
-
- 23 Oct, 2008 1 commit
-
-
Jonathan Perkin authored
-
- 02 Oct, 2008 1 commit
-
-
Sergey Glukhov authored
The '@' symbol can not be used in the host name according to rfc952. The fix: added function check_host_name(LEX_STRING *str) which checks that all symbols in host name string are valid and host name length is not more than max host name length (just moved check_string_length() function from the parser into check_host_name()).
-
- 11 Aug, 2008 1 commit
-
-
Marc Alff authored
This fix is for 5.0 only : back porting the 6.0 patch manually The parser code in sql/sql_yacc.yy needs to be more robust to out of memory conditions, so that when parsing a query fails due to OOM, the thread gracefully returns an error. Before this fix, a new/alloc returning NULL could: - cause a crash, if dereferencing the NULL pointer, - produce a corrupted parsed tree, containing NULL nodes, - alter the semantic of a query, by silently dropping token values or nodes With this fix: - C++ constructors are *not* executed with a NULL "this" pointer when operator new fails. This is achieved by declaring "operator new" with a "throw ()" clause, so that a failed new gracefully returns NULL on OOM conditions. - calls to new/alloc are tested for a NULL result, - The thread diagnostic area is set to an error status when OOM occurs. This ensures that a request failing in the server properly returns an ER_OUT_OF_RESOURCES error to the client. - OOM conditions cause the parser to stop immediately (MYSQL_YYABORT). This prevents causing further crashes when using a partially built parsed tree in further rules in the parser. No test scripts are provided, since automating OOM failures is not instrumented in the server. Tested under the debugger, to verify that an error in alloc_root cause the thread to returns gracefully all the way to the client application, with an ER_OUT_OF_RESOURCES error.
-
- 14 Jul, 2008 1 commit
-
-
Marc Alff authored
build) The crash was caused by freeing the internal parser stack during the parser execution. This occured only for complex stored procedures, after reallocating the parser stack using my_yyoverflow(), with the following C call stack: - MYSQLparse() - any rule calling sp_head::restore_lex() - lex_end() - x_free(lex->yacc_yyss), xfree(lex->yacc_yyvs) The root cause is the implementation of stored procedures, which breaks the assumption from 4.1 that there is only one LEX structure per parser call. The solution is to separate the LEX structure into: - attributes that represent a statement (the current LEX structure), - attributes that relate to the syntax parser itself (Yacc_state), so that parsing multiple statements in stored programs can create multiple LEX structures while not changing the unique Yacc_state. Now, Yacc_state and the existing Lex_input_stream are aggregated into Parser_state, a structure that represent the complete state of the (Lexical + Syntax) parser.
-
- 07 Jul, 2008 1 commit
-
-
Marc Alff authored
enabled) Before this fix, the lexer and parser would treat the ';' character as a different token (either ';' or END_OF_INPUT), based on convoluted logic, which failed in simple cases where a stored procedure is implemented as a single statement, and used in a multi query. With this fix: - the character ';' is always parsed as a ';' token in the lexer, - parsing multi queries is implemented in the parser, in the 'query:' rules, - the value of thd->client_capabilities, which is the capabilities negotiated between the client and the server during bootstrap, is immutable and not arbitrarily modified during parsing (which was the root cause of the bug)
-
- 26 Mar, 2008 1 commit
-
-
cmiller@zippy.cornsilk.net authored
-
- 14 Mar, 2008 1 commit
-
-
svoj@mysql.com/june.mysql.com authored
When there are no underlying tables specified for a merge table, SHOW CREATE TABLE outputs a statement that cannot be executed. The same is true for mysqldump (it generates dumps that cannot be executed). This happens because SQL parser does not accept empty UNION() clause. This patch changes the following: - it is now possible to execute CREATE/ALTER statement with empty UNION() clause. - the same as above, but still worth noting: it is now possible to remove underlying tables mapping using ALTER TABLE ... UNION=(). - SHOW CREATE TABLE does not output UNION() clause if there are no underlying tables specified for a merge table. This makes mysqldump slightly smaller.
-
- 28 Feb, 2008 1 commit
-
-
davi@mysql.com/endora.local authored
The problem is that passing anything other than a integer to a limit clause in a prepared statement would fail. This limitation was introduced to avoid replication problems (e.g: replicating the statement with a string argument would cause a parse failure in the slave). The solution is to convert arguments to the limit clause to a integer value and use this converted value when persisting the query to the log.
-
- 25 Feb, 2008 1 commit
-
-
kaa@kaamos.(none) authored
documentation While the manual mentions FRAC_SECOND only for the TIMESTAMPADD() function, it was also possible to use FRAC_SECOND with DATE_ADD(), DATE_SUB() and +/- INTERVAL. Fixed the parser to match the manual, i.e. using FRAC_SECOND for anything other than TIMESTAMPADD()/TIMESTAMPDIFF() now produces a syntax error. Additionally, the patch allows MICROSECOND to be used in TIMESTAMPADD/ TIMESTAMPDIFF and marks FRAC_SECOND as deprecated.
-
- 01 Feb, 2008 1 commit
-
-
kaa@mbp.local authored
on table creates The problem was in incompatible syntax for key definition in CREATE TABLE. 5.0 supports only the following syntax for key definition (see "CREATE TABLE syntax" in the manual): {INDEX|KEY} [index_name] [index_type] (index_col_name,...) While 5.1 parser supports the above syntax, the "preferred" syntax was changed to: {INDEX|KEY} [index_name] (index_col_name,...) [index_type] The above syntax is used in 5.1 for the SHOW CREATE TABLE output, which led to dumps generated by 5.1 being incompatible with 5.0. Fixed by changing the parser in 5.0 to support both 5.0 and 5.1 syntax for key definition.
-
- 23 Jan, 2008 1 commit
-
-
malff@lambda.hsd1.co.comcast.net. authored
Bug 33983 (Stored Procedures: wrong end <label> syntax is accepted) The server used to crash when REPEAT or another control instruction was used in conjunction with labels and a LEAVE instruction. The crash was caused by a missing "pop" of handlers or cursors in the code representing the stored program. When executing the code in a loop, this missing "pop" would result in a stack overflow, corrupting memory. Code generation has been fixed to produce the missing h_pop/c_pop instructions. Also, the logic checking that labels at the beginning and the end of a statement are matched was incorrect, causing Bug 33983. End labels, when used, must match the label used at the beginning of a block.
-
- 14 Dec, 2007 1 commit
-
-
igor@olga.mysql.com authored
In a union without braces, the order by at the end is applied to the overall union. It therefore should not interfere with the individual select parts of the union. Fixed by changing our parser rules appropriately.
-
- 13 Dec, 2007 1 commit
-
-
mhansson/martin@linux-st28.site authored
subselects into account It is forbidden to use the SELECT INTO construction inside UNION statements unless on the last SELECT of the union. The parser records whether it has seen INTO or not when parsing a UNION statement. But if the INTO was legally used in an outer query, an error is thrown if UNION is seen in a subquery. Fixed in 5.0 by remembering the nesting level of INTO tokens and mitigate the error unless it collides with the UNION.
-
- 03 Dec, 2007 1 commit
-
-
mhansson/martin@linux-st28.site authored
Anti-patch. This patch undoes the previously pushed patch. It is null-merged in versions 5.1 and above since there the original patch is still desired.
-
- 26 Nov, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
crashes MySQL 5.122 There was a difference in how UNIONs are handled on top level and when in sub-query. Because the rules for sub-queries were syntactically allowing cases that are not currently supported by the server we had crashes (this bug) or wrong results (bug 32051). Fixed by making the syntax rules for UNIONs match the ones at top level. These rules however do not support nesting UNIONs, e.g. (SELECT a FROM t1 UNION ALL SELECT b FROM t2) UNION (SELECT c FROM t3 UNION ALL SELECT d FROM t4) Supports for statements with nested UNIONs will be added in a future version.
-
- 21 Nov, 2007 1 commit
-
-
Problem: we have CHECK TABLE options allowed (by accident?) for ANALYZE/OPTIMIZE TABLE. Fix: disable them. Note: it might require additional fixes in 5.1/6.0
-
- 19 Nov, 2007 1 commit
-
-
thek@adventure.(none) authored
When the server was out of memory it crashed because of invalid memory access. This patch adds detection for failed memory allocations and make the server output a proper error message.
-
- 25 Oct, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
all space column names. The parser has been modified to check VIEW column names with the check_column_name function and to report an error on empty and all space column names (same as for TABLE column names).
-
- 16 Oct, 2007 2 commits
-
-
malff@lambda.hsd1.co.comcast.net. authored
-
malff@lambda.hsd1.co.comcast.net. authored
The root cause of the issue was that the CREATE FUNCTION grammar, for User Defined Functions, was using the sp_name rule. The sp_name rule is intended for fully qualified stored procedure names, like either ident.ident, or just ident but with a default database implicitly selected. A UDF does not have a fully qualified name, only a name (ident), and should not use the sp_name grammar fragment during parsing. The fix is to re-organize the CREATE FUNCTION grammar, to better separate: - creating UDF (no definer, can have AGGREGATE, simple ident) - creating Stored Functions (definer, no AGGREGATE, fully qualified name) With the test case provided, another issue was exposed which is also fixed: the DROP FUNCTION statement was using sp_name and also failing when no database is implicitly selected, when droping UDF functions. The fix is also to change the grammar so that DROP FUNCTION works with both the ident.ident syntax (to drop a stored function), or just the ident syntax (to drop either a UDF or a Stored Function, in the current database)
-
- 15 Oct, 2007 1 commit
-
-
gluh@mysql.com/eagle.(none) authored
issue an error if string has illegal characters
-
- 11 Oct, 2007 1 commit
-
-
gluh@mysql.com/eagle.(none) authored
Bug#30982 CHAR(..USING..) can return a not-well-formed string Bug#30986 Character set introducer followed by a HEX string can return bad result check_well_formed_result moved to Item from Item_str_func fixed Item_func_char::val_str for proper ucs symbols converting added check for well formed strings for correct conversion of constants with underscore charset
-
- 10 Oct, 2007 2 commits
-
-
gkodinov/kgeorge@magare.gmz authored
Fixed the usage of spatial data (and Point in specific) with non-spatial indexes. Several problems : - The length of the Point class was not updated to include the spatial reference system identifier. Fixed by increasing with 4 bytes. - The storage length of the spatial columns was not accounting for the length that is prepended to it. Fixed by treating the spatial data columns as blobs (and thus increasing the storage length) - When creating the key image for comparison in index read wrong key image was created (the one needed for and r-tree search, not the one for b-tree/other search). Fixed by treating the spatial data columns as blobs (and creating the correct kind of image based on the index type).
-
cmiller@zippy.cornsilk.net authored
sql_yacc.yy Yacc rules lacked semicolons to terminate rules, which is illegal in old versions of bison. Added semicolons.
-
- 09 Oct, 2007 1 commit
-
-
Bug#29816 Syntactically wrong query fails with misleading error message The core problem is that an SQL-invoked function name can be a <schema qualified routine name> that contains no <schema name>, but the mysql parser insists that all stored procedures (function, procedures and triggers) must have a <schema name>, which is not true for functions. This problem is especially visible when trying to create a function or when a query contains a syntax error after a function call (in the same query), both will fail with a "No database selected" message if the session is not attached to a particular schema, but the first one should succeed and the second fail with a "syntax error" message. Part of the fix is to revamp the sp name handling so that a schema name may be omitted for functions -- this means that the internal function name representation may not have a dot, which represents that the function doesn't have a schema name. The other part is to place schema checks after the type (function, trigger or procedure) of the routine is known.
-
- 03 Sep, 2007 1 commit
-
-
mhansson/martin@linux-st28.site authored
DELETE FROM ... USING ... statements with the following type of ambiguous aliasing gave unexpected results: DELETE FROM t1 AS alias USING t1, t2 AS alias WHERE t1.a = alias.a; This query would leave table t1 intact but delete rows from t2. Fixed by changing DELETE FROM ... USING syntax so that only alias references (as opposed to alias declarations) may be used in FROM.
-
- 31 Aug, 2007 1 commit
-
-
cmiller@zippy.cornsilk.net authored
Based on contributed patch from Martin Friebe, CLA from 2007-02-24. The parser lacked support for field sizes after signed long, when it should extend to 2**32-1. Now, we correct that limitation, and also make the error handling consistent for casts.
-
- 28 Aug, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
This is a performance bug, affecting in particular the bison generated code for the parser. Prior to this fix, the grammar used a long chain of reduces to parse an expression, like: bit_expr -> bit_term bit_term -> bit_factor bit_factor -> value_expr value_expr -> term term -> factor etc This chain of reduces cause the internal state automaton in the generated parser to execute more state transitions and more reduces, so that the generated MySQLParse() function would spend a lot of time looping to execute all the grammar reductions. With this patch, the grammar has been reorganized so that rules are more "flat", limiting the depth of reduces needed to parse <expr>. Tests have been written to enforce that relative priorities and properties of operators have not changed while changing the grammar. See the bug report for performance data.
-