An error occurred fetching the project authors.
- 12 Sep, 2006 2 commits
-
-
timour/timka@lamia.home authored
The cause of the bug was an incomplete fix for bug 18080. The problem was that setup_tables() unconditionally reset the name resolution context to its 'tables' argument, which pointed to the first table of an SQL statement. The bug fix limits resetting of the name resolution context in setup_tables() only in the cases when the context was not set by earlier parser/optimizer phases.
-
andrey@example.com authored
Remove SHOW SCHEDULER STATUS command and migrate the information output to `mysqladmin debug` (COM_DEBUG) SHOW SCHEDULER STATUS was introduced in 5.1.11, provided some debug information about event scheduler internals and was enabled only in debug builds.
-
- 08 Sep, 2006 1 commit
-
-
gluh@mysql.com/gluh.(none) authored
-
- 07 Sep, 2006 1 commit
-
-
gluh@mysql.com/gluh.(none) authored
-
- 01 Sep, 2006 1 commit
-
-
jimw@rama.(none) authored
Identifiers with embedded escape characters were not handled correctly by some SHOW statements due to some old code that was doing some extra unescaping.
-
- 30 Aug, 2006 1 commit
-
-
gluh@mysql.com/gluh.(none) authored
Bug#21432 Database/Table name limited to 64 bytes, not chars, problems with multi-byte
-
- 28 Aug, 2006 1 commit
-
-
andrey@example.com authored
Don't send affected rows after CREATE/ALTER/DROP EVENT as this is inconsistent with the rest of the server in terms of CREATE/ALTER/DROP DDLs
-
- 25 Aug, 2006 1 commit
-
-
andrey@example.com authored
erroneous check Problem: Actually there were two problems in the server code. The check for SQLCOM_FLUSH in SF/Triggers were not according to the existing architecture which uses sp_get_flags_for_command() from sp_head.cc . This function was also missing a check for SQLCOM_FLUSH which has a problem combined with prelocking. This changeset fixes both of these deficiencies as well as the erroneous check in sp_head::is_not_allowed_in_function() which was a copy&paste error.
-
- 24 Aug, 2006 1 commit
-
-
anozdrin/alik@alik. authored
User name (host name) has limit on length. The server code relies on these limits when storing the names. The problem was that sometimes these limits were not checked properly, so that could lead to buffer overflow. The fix is to check length of user/host name in parser and if string is too long, throw an error.
-
- 23 Aug, 2006 2 commits
-
-
evgen@sunlight.local authored
Corrected test case for the bug#21261 sql_parse.cc: Corrected fix for bug#21261
-
anozdrin/alik@alik. authored
User name (host name) has limit on length. The server code relies on these limits when storing the names. The problem was that sometimes these limits were not checked properly, so that could lead to buffer overflow. The fix is to check length of user/host name in parser and if string is too long, throw an error.
-
- 19 Aug, 2006 1 commit
-
-
malff/marcsql@weblab.(none) authored
Corrected build issues : the build can not be conditional. to keep a unique source .tar.gz distribution.
-
- 17 Aug, 2006 2 commits
-
-
malff/marcsql@weblab.(none) authored
Changed the automake build process : - ./configure.in - ./sql/Makefile.am to compile an instrumented parser for debug=yes or debug=full builds Changed the (primary) runtime invocation of the parser : - sql/sql_parse.cc to generate bison traces in stderr when the DBUG "parser_debug" flag is set.
-
andrey@example.com authored
There is an existing macros for initializing LEX_STRINGs with constant strings -> C_STRING_WITH_LEN. Change existing code to use it. (char *) STRING_WITH_LEN -> C_STRING_WITH_LEN
-
- 09 Aug, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
-
- 20 Jul, 2006 1 commit
-
-
sergefp@mysql.com authored
Add implementations of Item_func_{nop,not}_all::neg_transformer
-
- 19 Jul, 2006 1 commit
-
-
kostja@bodhi.local authored
"real" table fails in JOINs". This is a regression caused by the fix for Bug 18444. This fix removed the assignment of empty_c_string to table->db performed in add_table_to_list, as neither me nor anyone else knew what it was there for. Now we know it and it's covered with tests: the only case when a table database name can be empty is when the table is a derived table. The fix puts the assignment back but makes it a bit more explicit. Additionally, finally drop sp.result.orig which was checked in by mistake.
-
- 18 Jul, 2006 1 commit
-
-
holyfoot/hf@mysql.com/deer.(none) authored
-
- 13 Jul, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
context. Routine arguments were evaluated in the security context of the routine itself, not in the caller's context. The bug is fixed the following way: - Item_func_sp::find_and_check_access() has been split into two functions: Item_func_sp::find_and_check_access() itself only finds the function and check that the caller have EXECUTE privilege on it. New function set_routine_security_ctx() changes security context for SUID routines and checks that definer have EXECUTE privilege too. - new function sp_head::execute_trigger() is called from Table_triggers_list::process_triggers() instead of sp_head::execute_function(), and is effectively just as the sp_head::execute_function() is, with all non-trigger related code removed, and added trigger-specific security context switch. - call to Item_func_sp::find_and_check_access() stays outside of sp_head::execute_function(), and there is a code in sql_parse.cc before the call to sp_head::execute_procedure() that checks that the caller have EXECUTE privilege, but both sp_head::execute_function() and sp_head::execute_procedure() call set_routine_security_ctx() after evaluating their parameters, and restore the context after the body is executed.
-
- 11 Jul, 2006 1 commit
-
-
andrey@lmy004. authored
More small fixes to the API : use LEX_STRING instead of LEX_STRING* and if error then return bool(true) instead of error code. Merged functions. Reduced usage of sp_name. Fixed a lot of function documentation errors. Added function documentation wherever needed. Removed some unused defines and error codes. Next to come is batch rename of Event_scheduler_ng to Event_scheduler.
-
- 10 Jul, 2006 2 commits
-
-
guilhem@gbichot3.local authored
We now reset the THD members related to auto_increment+binlog in MYSQL_LOG::write(). This is better than in THD::cleanup_after_query(), which was not able to distinguish between SELECT myfunc1(),myfunc2() and INSERT INTO t SELECT myfunc1(),myfunc2() from a binlogging point of view. Rows_log_event::exec_event() now calls lex_start() instead of mysql_init_query() because the latter now does too much (it resets the binlog format).
-
andrey@lmy004. authored
This patch introduces specialized Event data objects Event_basic as parent. Event_queue_element used for queue storage Event_timed used for SHOW EVENTS/ I_S.EVENTS / SHOW CREATE EVENT Event_job_data using during execution. Methods were moved out of Event_timed to other classes. This patch also introduces Events::LOCK_event_metadata. This patch gives new implementation of Events::dump_internal_status(). Now both the Event_scheduler and Event_queue return information during their ::dump_internal_status(). Shortened a bit the runtime for executing events test cases.
-
- 09 Jul, 2006 2 commits
-
-
guilhem@gbichot3.local authored
this is a cleanup patch for our current auto_increment handling: new names for auto_increment variables in THD, new methods to manipulate them (see sql_class.h), some move into handler::, causing less backup/restore work when executing substatements. This makes the logic hopefully clearer, less work is is needed in mysql_insert(). By cleaning up, using different variables for different purposes (instead of one for 3 things...), we fix those bugs, which someone may want to fix in 5.0 too: BUG#20339 "stored procedure using LAST_INSERT_ID() does not replicate statement-based" BUG#20341 "stored function inserting into one auto_increment puts bad data in slave" BUG#19243 "wrong LAST_INSERT_ID() after ON DUPLICATE KEY UPDATE" (now if a row is updated, LAST_INSERT_ID() will return its id) and re-fixes: BUG#6880 "LAST_INSERT_ID() value changes during multi-row INSERT" (already fixed differently by Ramil in 4.1) Test of documented behaviour of mysql_insert_id() (there was no test). The behaviour changes introduced are: - LAST_INSERT_ID() now returns "the first autogenerated auto_increment value successfully inserted", instead of "the first autogenerated auto_increment value if any row was successfully inserted", see auto_increment.test. Same for mysql_insert_id(), see mysql_client_test.c. - LAST_INSERT_ID() returns the id of the updated row if ON DUPLICATE KEY UPDATE, see auto_increment.test. Same for mysql_insert_id(), see mysql_client_test.c. - LAST_INSERT_ID() does not change if no autogenerated value was successfully inserted (it used to then be 0), see auto_increment.test. - if in INSERT SELECT no autogenerated value was successfully inserted, mysql_insert_id() now returns the id of the last inserted row (it already did this for INSERT VALUES), see mysql_client_test.c. - if INSERT SELECT uses LAST_INSERT_ID(X), mysql_insert_id() now returns X (it already did this for INSERT VALUES), see mysql_client_test.c. - NDB now behaves like other engines wrt SET INSERT_ID: with INSERT IGNORE, the id passed in SET INSERT_ID is re-used until a row succeeds; SET INSERT_ID influences not only the first row now. Additionally, when unlocking a table we check that the thread is not keeping a next_insert_id (as the table is unlocked that id is potentially out-of-date); forgetting about this next_insert_id is done in a new handler::ha_release_auto_increment(). Finally we prepare for engines capable of reserving finite-length intervals of auto_increment values: we store such intervals in THD. The next step (to be done by the replication team in 5.1) is to read those intervals from THD and actually store them in the statement-based binary log. NDB will be a good engine to test that.
-
guilhem@gbichot3.local authored
1) Fix for BUG#19630 "stored function inserting into two auto_increment breaks statement-based binlog": a stored function inserting into two such tables may fail to replicate (inserting wrong data in the slave's copy of the second table) if the slave's second table had an internal auto_increment counter different from master's. Because the auto_increment value autogenerated by master for the 2nd table does not go into binlog, only the first does, so the slave lacks information. To fix this, if running in mixed binlogging mode, if the stored function or trigger plans to update two different tables both having auto_increment columns, we switch to row-based for the whole function. We don't have a simple solution for statement-based binlogging mode, there the bug remains and will be documented as a known problem. Re-enabling rpl_switch_stm_row_mixed. 2) Fix for BUG#20630 "Mixed binlogging mode does not work with stored functions, triggers, views", which was a documented limitation (in mixed mode, we didn't detect that a stored function's execution needed row-based binlogging (due to some UUID() call for example); same for triggers, same for views (a view created from a SELECT UUID(), and doing INSERT INTO sometable SELECT theview; would not replicate row-based). This is implemented by, after parsing a routine's body, remembering in sp_head that this routine needs row-based binlogging. Then when this routine is used, the caller is marked to require row-based binlogging too. Same for views: when we parse a view and detect that its SELECT needs row-based binary logging, we mark the calling LEX as such. 3) Fix for BUG#20499 "mixed mode with temporary table breaks binlog": a temporary table containing e.g. UUID has its changes not binlogged, so any query updating a permanent table with data from the temporary table will run wrongly on slave. Solution: in mixed mode we don't switch back from row-based to statement-based when there exists temporary tables. 4) Attempt to test mysqlbinlog on a binlog generated by mysqlbinlog; impossible due to BUG#11312 and BUG#20329, but test is in place for when they are fixed.
-
- 06 Jul, 2006 1 commit
-
-
konstantin@bodhi.netgear authored
-
- 05 Jul, 2006 1 commit
-
-
andrey@lmy004. authored
Cleaned up the code a bit. Fixed few leaks. This code still does not load events on server startup from disk. The problem is that there is a need for a THD instance, which does not exist during server boot. This will be solved soon. Still Event_timed is used both for the memory queue and for exectution. This will be changed according to WL#3337 probably in the next commit.
-
- 04 Jul, 2006 1 commit
-
-
konstantin@mysql.com authored
run at startup" The server returned an error when trying to execute init-file with a stored procedure that could return multiple result sets to the client. A stored procedure can return multiple result sets if it contains PREPARE, SELECT, SHOW and similar statements. The fix is to set client_capabilites|=CLIENT_MULTI_RESULTS in sql_parse.cc:handle_bootstrap(). There is no "client" really, so nothing is ever sent. This makes init-file feature behave consistently: the prepared statements that can be called directly in the init-file can be used in a stored procedure too. Re-committed the patch originally submitted by Per-Erik after review.
-
- 03 Jul, 2006 1 commit
-
-
konstantin@mysql.com authored
-
- 01 Jul, 2006 1 commit
-
-
dlenev@mysql.com authored
NDB table". SQL-layer was not marking fields which were used in triggers as such. As result these fields were not always properly retrieved/stored by handler layer. So one might got wrong values or lost changes in triggers for NDB, Federated and possibly InnoDB tables. This fix solves the problem by marking fields used in triggers appropriately. Also this patch contains the following cleanup of ha_ndbcluster code: We no longer rely on reading LEX::sql_command value in handler in order to determine if we can enable optimization which allows us to handle REPLACE statement in more efficient way by doing replaces directly in write_row() method without reporting error to SQL-layer. Instead we rely on SQL-layer informing us whether this optimization applicable by calling handler::extra() method with HA_EXTRA_WRITE_CAN_REPLACE flag. As result we no longer apply this optimzation in cases when it should not be used (e.g. if we have on delete triggers on table) and use in some additional cases when it is applicable (e.g. for LOAD DATA REPLACE). Finally this patch includes fix for bug#20728 "REPLACE does not work correctly for NDB table with PK and unique index". This was yet another problem which was caused by improper field mark-up. During row replacement fields which weren't explicity used in REPLACE statement were not marked as fields to be saved (updated) so they have retained values from old row version. The fix is to mark all table fields as set for REPLACE statement. Note that in 5.1 we already solve this problem by notifying handler that it should save values from all fields only in case when real replacement happens.
-
- 30 Jun, 2006 1 commit
-
-
konstantin@mysql.com authored
-
- 29 Jun, 2006 1 commit
-
-
gluh@eagle.intranet.mysql.r18.ru authored
user name is calculated on function execution stage instead of parse stage
-
- 28 Jun, 2006 2 commits
-
-
andrey@lmy004. authored
This cut No 7 should finish the part of fixing the parsing of the events : - Event_timed is no more used during parsing. Less problems because it has a mutex. Event_parse_data class is used during parsing. It is suited only for this purpose. It's pretty lightweight - Late checking of data from parsing is being performed. This should solve the problems of nested events in SP or other events (for the situation of no nested bodies). Before if an ALTER EVENT was in a SP, then when the SP was compiled, and not executed, the actual init_xxx methods of Event_timed were called, which is wrong. - It could be a side effect of using a specialized class, but test events_stress is now 25% quicker. Cut No8 will start splitting Event_scheduler into 2 parts, the QUEUE will be moved to Event_queue.
-
monty@mysql.com authored
(Found by dgcov)
-
- 27 Jun, 2006 5 commits
-
-
andrey@lmy004. authored
5th cut, moved DB related code to Event_db_repository and updated accordingly the remanining code. Moved change/restore_security_context() to class THD Removed events_priv.h Next step is to reorganize create/update_event() and parsing for them. But probably some other refactoring could be done in the meanwhile. The changes so far pass the test suite.
-
svoj@may.pils.ru authored
Produce a warning if DATA/INDEX DIRECTORY is specified in ALTER TABLE statement. Ignoring of these options is documented in the symbolic links section of the manual.
-
andrey@lmy004. authored
Third cut to simplify parsing phase. Now DROP EVENT works. Overloaded few functions to be able to use either sp_name or pass two LEX_STRINGs instead of a Event_timed pointer. This is transitional and eventually the old functions will be removed. For now DROP EVENT also works, does not need anymore a parsing object (Event_timed) and definer initialization because everyone who has EVENT_ACL can drop events, and this is checked on execution time in sql_parse.cc from the security context, as it should be.
-
andrey@lmy004. authored
Second cut of separating parsing phase from execution phase Separate Event_timed from parsing phase and introducing Event_parse_data.
-
andrey@lmy004. authored
Infrastructure built. Added the foreseen files and change Makefile.am/CMakeLists.txt accordingly.
-
- 26 Jun, 2006 2 commits
-
-
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.
-
ingo@mysql.com authored
Addendum fixes after changing the condition variable for the global read lock. The stress test suite revealed some deadlocks. Some were related to the new condition variable (COND_global_read_lock) and some were general problems with the global read lock. It is now necessary to signal COND_global_read_lock whenever COND_refresh is signalled. We need to wait for the release of a global read lock if one is set before every operation that requires a write lock. But we must not wait if we have locked tables by LOCK TABLES. After setting a global read lock a thread waits until all write locks are released.
-