An error occurred fetching the project authors.
- 07 Mar, 2007 2 commits
-
-
kostja@bodhi.local authored
-
kostja@bodhi.local authored
fixes). The legend: on a replication slave, in case a trigger creation was filtered out because of application of replicate-do-table/ replicate-ignore-table rule, the parsed definition of a trigger was not cleaned up properly. LEX::sphead member was left around and leaked memory. Until the actual implementation of support of replicate-ignore-table rules for triggers by the patch for Bug 24478 it was never the case that "case SQLCOM_CREATE_TRIGGER" was not executed once a trigger was parsed, so the deletion of lex->sphead there worked and the memory did not leak. The fix: The real cause of the bug is that there is no 1 or 2 places where we can clean up the main LEX after parse. And the reason we can not have just one or two places where we clean up the LEX is asymmetric behaviour of MYSQLparse in case of success or error. One of the root causes of this behaviour is the code in Item::Item() constructor. There, a newly created item adds itself to THD::free_list - a single-linked list of Items used in a statement. Yuck. This code is unaware that we may have more than one statement active at a time, and always assumes that the free_list of the current statement is located in THD::free_list. One day we need to be able to explicitly allocate an item in a given Query_arena. Thus, when parsing a definition of a stored procedure, like CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END; we actually need to reset THD::mem_root, THD::free_list and THD::lex to parse the nested procedure statement (SELECT *). The actual reset and restore is implemented in semantic actions attached to sp_proc_stmt grammar rule. The problem is that in case of a parsing error inside a nested statement Bison generated parser would abort immediately, without executing the restore part of the semantic action. This would leave THD in an in-the-middle-of-parsing state. This is why we couldn't have had a single place where we clean up the LEX after MYSQLparse - in case of an error we needed to do a clean up immediately, in case of success a clean up could have been delayed. This left the door open for a memory leak. One of the following possibilities were considered when working on a fix: - patch the replication logic to do the clean up. Rejected as breaks module borders, replication code should not need to know the gory details of clean up procedure after CREATE TRIGGER. - wrap MYSQLparse with a function that would do a clean up. Rejected as ideally we should fix the problem when it happens, not adjust for it outside of the problematic code. - make sure MYSQLparse cleans up after itself by invoking the clean up functionality in the appropriate places before return. Implemented in this patch. - use %destructor rule for sp_proc_stmt to restore THD - cleaner than the prevoius approach, but rejected because needs a careful analysis of the side effects, and this patch is for 5.0, and long term we need to use the next alternative anyway - make sure that sp_proc_stmt doesn't juggle with THD - this is a large work that will affect many modules. Cleanup: move main_lex and main_mem_root from Statement to its only two descendants Prepared_statement and THD. This ensures that when a Statement instance was created for purposes of statement backup, we do not involve LEX constructor/destructor, which is fairly expensive. In order to track that the transformation produces equivalent functionality please check the respective constructors and destructors of Statement, Prepared_statement and THD - these members were used only there. This cleanup is unrelated to the patch.
-
- 06 Mar, 2007 1 commit
-
-
kostja@bodhi.local authored
-
- 02 Mar, 2007 2 commits
-
-
kostja@bodhi.local authored
conflicts without proper analysis and documentation of the nature of the conflict.
-
kostja@bodhi.local authored
-
- 01 Mar, 2007 1 commit
-
-
rafal@quant.(none) authored
-
- 28 Feb, 2007 1 commit
-
-
bar@mysql.com authored
This patch fixes problem that LOAD DATA could use different character sets when loading files on master and on slave sides: - Adding replication of thd->variables.collation_database - Adding optional character set clause into LOAD DATA Note, the second way, with explicit CHARACTER SET clause should be the recommended way to load data using an alternative character set. The old way, using "SET @@character_set_database=xxx" should be gradually depricated.
-
- 24 Feb, 2007 1 commit
-
-
evgen@moonbone.local authored
Post fix for bug#23800. The Item_field constructor now increases the select_n_where_fields counter. sql_yacc.yy: Post fix for bug#23800. Take into account fields that might be added by subselects. sql_lex.h: Post fix for bug#23800. Added the select_n_where_fields variable to the st_select_lex class. sql_lex.cc: Post fix for bug#23800. Initialization of the select_n_where_fields variable.
-
- 23 Feb, 2007 1 commit
-
-
monty@mysql.com/narttu.mysql.fi authored
-
- 19 Feb, 2007 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
Several problems fixed: 1. There was a "catch-all" context initialization in setup_tables() that was causing the table that we insert into to be visible in the SELECT part of an INSERT .. SELECT .. statement with no tables in its FROM clause. This was making sure all the under-initialized contexts in various parts of the code are not left uninitialized. Fixed by removing the "catch-all" statement and initializing the context in the parser. 2. Incomplete name resolution context when resolving the right-hand values in the ON DUPLICATE KEY UPDATE ... part of an INSERT ... SELECT ... caused columns from NATURAL JOIN/JOIN USING table references in the FROM clause of the select to be unavailable. Fixed by establishing a proper name resolution context. 3. When setting up the special name resolution context for problem 2 there was no check for cases where an aggregate function without a GROUP BY effectively takes the column from the SELECT part of an INSERT ... SELECT unavailable for ON DUPLICATE KEY UPDATE. Fixed by checking for that condition when setting up the name resolution context.
-
- 13 Feb, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
-
- 12 Feb, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
operations) Before this change, the boolean predicates: - X IS TRUE, - X IS NOT TRUE, - X IS FALSE, - X IS NOT FALSE were implemented by expanding the Item tree in the parser, by using a construct like: Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>) Each <value> was a constant integer, either 0 or 1. A bug in the implementation of the function IF(a, b, c), in Item_func_if::fix_length_and_dec(), would cause the following : When the arguments b and c are both unsigned, the result type of the function was signed, instead of unsigned. When the result of the if function is signed, space for the sign could be counted twice (in the max() expression for a signed argument, and in the total), causing the member max_length to be too high. An effect of this is that the final type of IF(x, int(1), int(1)) would be int(2) instead of int(1). With this fix, the problems found in Item_func_if::fix_length_and_dec() have been fixed. While it's semantically correct to represent 'X IS TRUE' with Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>), there are however more problems with this construct. a) Building the parse tree involves : - creating 5 Item instances (3 ints, 1 ifnull, 1 if), - creating each Item calls my_pthread_getspecific_ptr() once in the operator new(size), and a second time in the Item::Item() constructor, resulting in a total of 10 calls to get the current thread. Evaluating the expression involves evaluating up to 4 nodes at runtime. This representation could be greatly simplified and improved. b) Transforming the parse tree internally with if(ifnull(...)) is fine as long as this transformation is internal to the server implementation. With views however, the result of the parse tree is later exposed by the ::print() functions, and stored as part of the view definition. Doing this has long term consequences: 1) The original semantic 'X IS TRUE' is lost, and replaced by the if(ifnull(...)) expression. As a result, SHOW CREATE VIEW does not restore the original code. 2) Should a future version of MySQL implement the SQL BOOLEAN data type for example, views created today using 'X IS NULL' can be exported using mysqldump, and imported again. Such views would be converted correctly and automatically to use a BOOLEAN column in the future version. With 'X IS TRUE' and the current implementations, views using these "boolean" predicates would not be converted during the export/import, and would use integer columns instead. The difference traces back to how SHOW CREATE VIEW preserves 'X IS NULL' but does not preserve the 'X IS TRUE' semantic. With this fix, internal representation of 'X IS TRUE' booleans predicates has changed, so that: - dedicated Item classes are created for each predicate, - only 1 Item is created to represent 1 predicate - my_pthread_getspecific_ptr() is invoked 1 time instead of 10 - SHOW CREATE VIEW preserves the original semantic, and prints 'X IS TRUE'. Note that, because of the fix in Item_func_if, views created before this fix will: - correctly use a int(1) type instead of int(2) for boolean predicates, - incorrectly print the if(ifnull(...), ...) expression in SHOW CREATE VIEW, since the original semantic (X IS TRUE) has been lost. - except for the syntax used in SHOW CREATE VIEW, these views will operate properly, no action is needed. Views created after this fix will operate correctly, and will preserve the original code semantic in SHOW CREATE VIEW.
-
- 07 Feb, 2007 1 commit
-
-
antony@ppcg5.local authored
"CONNECTION is a reserved keyword" Allow connection to be used as an ordinary identifier Tests included.
-
- 02 Feb, 2007 1 commit
-
-
kroki/tomash@moonlight.home authored
There was already support for CREATE DEFINER=... EVENT syntax in the parser, but DEFINER information was ignored. This patch adds processing of DEFINER, and a new ALTER DEFINER=... EVENT syntax.
-
- 31 Jan, 2007 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
Two problems here: Problem 1: While constructing the join columns list the optimizer does as follows: 1. Sets the join_using_fields/natural_join members of the right JOIN operand. 2. Makes a "table reference" (TABLE_LIST) to parent the two tables. 3. Assigns the join_using_fields/is_natural_join of the wrapper table using join_using_fields/natural_join of the rightmost table 4. Sets join_using_fields to NULL for the right JOIN operand. 5. Passes the parent table up to the same procedure on the upper level. Step 1 overrides the the join_using_fields that are set for a nested join wrapping table in step 4. Fixed by making a designated variable SELECT_LEX::prev_join_using to pass the data from step 1 to step 4 without destroying the wrapping table data. Problem 2: The optimizer checks for ambiguous columns while transforming NATURAL JOIN/JOIN USING to JOIN ON. While doing that there was no distinction between columns that are used in the generated join condition (where ambiguity can be checked) and the other columns (where ambiguity can be checked only when resolving references coming from outside the JOIN construct itself). Fixed by allowing the non-USING columns to be present in multiple copies in both sides of the join and moving the ambiguity check to the place where unqualified references to the join columns are resolved (find_field_in_natural_join()).
-
- 30 Jan, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
Before this fix, a IN predicate of the form: "IN (( subselect ))", with two parenthesis, would be evaluated as a single row subselect: if the subselect returns more that 1 row, the statement would fail. The SQL:2003 standard defines a special exception in the specification, and mandates that this particular form of IN predicate shall be equivalent to "IN ( subselect )", which involves a table subquery and works with more than 1 row. This fix implements "IN (( subselect ))", "IN ((( subselect )))" etc as per the SQL:2003 requirement. All the details related to the implementation of this change have been commented in the code, and the relevant sections of the SQL:2003 spec are given for reference, so they are not repeated here. Having access to the spec is a requirement to review in depth this patch.
-
- 28 Jan, 2007 1 commit
-
-
monty@mysql.com/narttu.mysql.fi authored
Removed a lot of compiler warnings Removed not used variables, functions and labels Initialize some variables that could be used unitialized (fatal bugs) %ll -> %l
-
- 24 Jan, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
The build scripts in general, using automake, autoconf, etc, contain several special commands and work around all related to the way the bison code in the parser is built, for sql/sql_yacc.yy. These work arounds, accumulated over time during development, ultimately cause the build scripts to be unstable and cause build defects by not enforcing dependencies. This fix simplifies the build process and aligns it with the automake tooling, which provides native support for bison and *.yy files. In particular, the following problem have been fixed: - dependencies with sql_yacc.cc were not honored (Bug 21029), leading to corrupted builds, - the work around introduced by Bug 24557, to cleanup the generated files sql_yacc.h and sql_yacc.cc, has been removed, - the generated makefile, in a source distribution, used to destroy the files sql_yacc.h and sql_yacc.cc on a 'make clean' target. This has been fixed: these files are now removed by make maintainer-clean. - The root cause of the problem found with gcc 4.1 (see Bug 24619) has been clearly documented, and the "sed" hack has been replaced by a cleaner work around, when building the code with bison 1.875. - Removed the file sql/sql_yacc.yy.bak, added by WL 3031 by accident. - Removed the unnecessary AM_YFLAG= --debug introduced by WL 3432, since the compiling option DBUG_OFF takes precedence when setting YYDEBUG.
-
- 23 Jan, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
Before this fix, the command SHOW ENGINE <name> STATUS would: - print a warning if the engine name is unknown, - proceed and implement the same behavior as SHOW ENGINE ALL STATUS, and list the status of all the storage engines registered. In particular, this behavior caused confusion about the command : SHOW ENGINE MUTEX STATUS, which as a side effect would print the status of the innodb engine when that engine is registered. Also, before this fix, every time an unknown engine name was substituted by the default engine (which happen unless SQL_MODE NO_ENGINE_SUBSTITUTION is set), a malformed warning was raised. For example, the command ALTER TABLE T1 ENGINE = X would print : Warnings: Error 1286 Unknown table engine 'X' With this fix: SHOW ENGINE <name> STATUS|LOGS|MUTEX always fails with an error when the engine <name> is unknown. For other commands, warnings about unknown engines are raised as: Warnings: Warning 1286 Unknown table engine 'X' In other words, engine substitution never affect the SHOW ENGINE command, since this would lead to very confusing results.
-
- 19 Jan, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
-
- 18 Jan, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
WL#3681 (ALTER TABLE ORDER BY) Before this fix, the ALTER TABLE statement implemented an ORDER BY option with the following characteristics : 1) The order by clause accepts a list of criteria, with optional ASC or DESC keywords 2) Each criteria can be a general expression, involving operators, native functions, stored functions, user defined functions, subselects ... With this fix : 1) has been left unchanged, since it's a de-facto existing feature, that was already present in the code base and partially covered in the test suite. Code coverage for ASC and DESC was missing and has been improved. 2) has been changed to limit the kind of criteria that are permissible: now only a column name is valid.
-
- 11 Jan, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
According to some internal communication, these two functions are place holders for future enhancements. Because they use a variable number of parameters, the implementation defined a reserved keyword for them in the parser grammar. Unfortunately, doing so creates a bug similar to Bug 21114 reported for the function FORMAT. In the 5.1 code base, due to improvements in the code implemented with bug 21114, having a reserved keyword for functions with a variable number of arguments is not needed any more by the implementation. As a result, this fix removes the place-holder implementation, and removes the unnecessary reserved keywords. Should the functions UNIQUE_USERS and GROUP_UNIQUE_USERS be finally implemented in a later release, the implementation should sub class Create_native_func in sql/item_create.cc. For example, see the class Create_func_concat.
-
- 03 Jan, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
This fix corrects build issues introduced by WL#3031: - In the SQL grammar, 'USER' is a SQL 2003 reserved keyword, and therefore should not be part of the keyword production. - In sql/sql_parse.cc, the code for CREATE SERVER and ALTER SERVER was not using proper format strings in the DBUG_PRINT statements.
-
- 23 Dec, 2006 1 commit
-
-
kent@mysql.com/kent-amd64.(none) authored
Changed header to GPL version 2 only
-
- 19 Dec, 2006 1 commit
-
-
mskold/marty@mysql.com/linux.site authored
bug#24667 After ALTER TABLE operation ndb_dd table becomes regular ndb: ALTER TABLE must specify STORAGE explicitely to change it, + post review changes
-
- 14 Dec, 2006 1 commit
-
-
monty@mysql.com/narttu.mysql.fi authored
- Removed not used variables and functions - Added #ifdef around code that is not used - Renamed variables and functions to avoid conflicts - Removed some not used arguments Fixed some class/struct warnings in ndb Added define IS_LONGDATA() to simplify code in libmysql.c I did run gcov on the changes and added 'purecov' comments on almost all lines that was not just variable name changes
-
- 12 Dec, 2006 1 commit
-
-
malff/marcsql@weblab.(none) authored
-
- 11 Dec, 2006 2 commits
-
-
malff/marcsql@weblab.(none) authored
limitation) Bug#24854 (Mixing Searched Case with Simple Case inside Stored Procedure crashes Mysqld) Implemented code review (19194) comments
-
kostja@bodhi.local authored
on altered table" and Bug#19733 "Repeated alter, or repeated create/drop, fails"
-
- 09 Dec, 2006 1 commit
-
-
patg@govinda.patg.net authored
Post-commit issues fixed * Test results for other tests fixed due to added error #s * Memory allocation/free issues found with running with valgrind * Fix to mysql-test-run shell script to run federated_server test (installs mysql.servers table properly)
-
- 07 Dec, 2006 2 commits
-
-
kostja@bodhi.local authored
Bug#4968 "Stored procedure crash if cursor opened on altered table" Bug#19733 "Repeated alter, or repeated create/drop, fails" Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from stored procedure." Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing" Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server" Test cases for bugs 4968, 19733, 6895 will be added in 5.0. Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE statements in stored routines or as prepared statements caused incorrect results (and crashes in versions prior to 5.0.25). In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options). The problem of bugs 4968, 19733, 19282 and 6895 was that functions mysql_prepare_table, mysql_create_table and mysql_alter_table were not re-execution friendly: during their operation they used to modify contents of LEX (members create_info, alter_info, key_list, create_list), thus making the LEX unusable for the next execution. In particular, these functions removed processed columns and keys from create_list, key_list and drop_list. Search the code in sql_table.cc for drop_it.remove() and similar patterns to find evidence. The fix is to supply to these functions a usable copy of each of the above structures at every re-execution of an SQL statement. To simplify memory management, LEX::key_list and LEX::create_list were added to LEX::alter_info, a fresh copy of which is created for every execution. The problem of crashing bug 22060 stemmed from the fact that the above metnioned functions were not only modifying HA_CREATE_INFO structure in LEX, but also were changing it to point to areas in volatile memory of the execution memory root. The patch solves this problem by creating and using an on-stack copy of HA_CREATE_INFO (note that code in 5.1 already creates and uses a copy of this structure in mysql_create_table()/alter_table(), but this approach didn't work well for CREATE TABLE SELECT statement).
-
andrey@example.com authored
-
- 04 Dec, 2006 2 commits
-
-
malff/marcsql@weblab.(none) authored
Fixed typos in the comments.
-
tsmith/tim@siva.hindu.god authored
mysql-5.1-build tree, in order to get it into mysql-5.1 faster. See comments from Marc's original push for patch details.
-
- 02 Dec, 2006 3 commits
-
-
malff/marcsql@weblab.(none) authored
Before this fix, a call to a User Defined Function (UDF) could, under some circumstances, be interpreted as a call to a Stored function instead. This occurred if a native function was invoked in the parameters for the UDF, as in "select my_udf(abs(x))". The root cause of this defect is the introduction, by the fix for Bug 21809, of st_select_lex::udf_list, and it's usage in the parser in sql_yacc.yy in the rule function_call_generic (in 5.1). While the fix itself for Bug 21809 is correct in 5.0, the code change merged into the 5.1 release created the issue, because the calls in 5.1 to : - lex->current_select->udf_list.push_front(udf) - lex->current_select->udf_list.pop() are not balanced in case of native functions, causing the udf_list, which is really a stack, to be out of sync with the internal stack maintained by the bison parser. Instead of moving the call to udf_list.pop(), which would have fixed the symptom, this patch goes further and removes the need for udf_list. This is motivated by two reasons: a) Maintaining a stack in the MySQL code in sync with the stack maintained internally in sql_yacc.cc (not .yy) is extremely dependent of the implementation of yacc/bison, and extremely difficult to maintain. It's also totally dependent of the structure of the grammar, and has a risk to break with regression defects each time the grammar itself is changed. b) The previous code did report construct like "foo(expr AS name)" as syntax errors (ER_PARSER_ERROR), which is incorrect, and misleading. The syntax is perfectly valid, as this expression is valid when "foo" is a UDF. Whether this syntax is legal or not depends of the semantic of "foo". With this change: a) There is only one stack (in bison), and no List<udf_func> to maintain. b) "foo(expr AS name)", when used incorrectly, is reported as semantic error: - ER_WRONG_PARAMETERS_TO_NATIVE_FCT (for native functions) - ER_WRONG_PARAMETERS_TO_STORED_FCT (for stored functions) This is achieved by the changes implemented in item_create.cc
-
brian@zim.(none) authored
This finishes the work (someone) started to remove FIELD_ types and use the Enum MYSQL types. The second part to this is to actually deprecate the FIELD defines in mysql_com.h
-
patg@radha.tangent.org authored
Backport of functionality in private 5.2 tree. Added new language to parser, new mysql.servers table and associated code to be used by the federated storage engine to allow central connection information per WL entry.
-
- 30 Nov, 2006 2 commits
-
-
monty@mysql.com/narttu.mysql.fi authored
Fixed compiler warnings (detected by VC++): - Removed not used variables - Added casts - Fixed wrong assignments to bool - Fixed wrong calls with bool arguments - Added missing argument to store(longlong), which caused wrong store method to be called.
-
monty@mysql.com/narttu.mysql.fi authored
- Removed not used variables - Changed some ulong parameters/variables to ulonglong (possible serious bug) - Added casts to get rid of safe assignment from longlong to long (and similar) - Added casts to function parameters - Fixed signed/unsigned compares - Added some constructores to structures - Removed some not portable constructs Better fix for bug Bug #21428 "skipped 9 bytes from file: socket (3)" on "mysqladmin shutdown" (Added new parameter to net_clear() to define when we want the communication buffer to be emptied)
-
- 29 Nov, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
Note that we ignore CONCURRENT if LOAD DATA CONCURRENT is used from inside a stored routine and MySQL is compiled with Query Cache support (this is not in the manual). The problem was that the condition test of "we are inside stored routine" was reversed, thus CONCURRENT _worked only_ from stored routine. The solution is to use proper condition test. No test case is provided because the test case would require a large amount of input, and it's hard to tell is SELECT is really blocked or just slow (subject to race).
-