An error occurred fetching the project authors.
- 26 Jan, 2014 1 commit
-
-
Michael Widenius authored
sql/item.h: Added cache for setup_natural_join_row_types sql/sql_base.cc: Cache old value of first_name_resolution_table for next call. (It's not safe to try to recalculate the value as the join structure may have been changed by the optimizer)
-
- 24 Jan, 2014 1 commit
-
-
Michael Widenius authored
Main fix was to not cache derivied tables as they may be temporary tables that are deleted before the next query. This was a bit tricky as Item_field::fix_fields depended on cached_tables to be set to resolve some columns. mysql-test/r/sp-bugs.result: Added test case mysql-test/t/sp-bugs.test: Added test case sql/item.cc: Fixed fix_outer_field to handle case where found field did not have in cached_table Idea is that if cached_table is not avaliable, use from_field->table->pos_in_table_list instead sql/records.cc: Also accept INTERNAL_TMP_TABLE for memmap sql/sql_base.cc: More DBUG_PRINT Fixed that setup_natural_join_row_types() is not run twice. Original code modified context->first_name_resolution_table also for second executions. This was wrong as this could give wrong results if some joins had been optimized away between calls. sql/sql_derived.cc: Mark derived tables as internal temporary tables (INTERNAL_TMP_TABLE), not as NON_TRANSACTIONAL_TMP_TABLE. This is more correct as the tables are not visible by the end user. sql/sql_insert.cc: Reset pos_in_table_list before calling fix_fields. One of the consequences of the change of not caching all generated tables in Item_ident is that pos_in_table_list needs to be correct in calls to fix_fields. sql/sql_lex.cc: More DBUG_PRINT sql/sql_parse.cc: Don't cache derivied tables as they may be temporary tables that are deleted before the next query sql/sql_select.cc: Reset table_vector. This was required as some code checked the vector to see if temporary tables had already been created. sql/table.cc: Mark tables with field translations as cacheable (as these will not disapper between stmt executions.
-
- 23 Jan, 2014 1 commit
-
-
unknown authored
THD::thd->activate_stmt_arena_if_needed() should be used to temporary activating statement arena instead of direct usage of THD::set_n_backup_active_arena() because possible such scenario: 1) func1 saves current arena and activates copy1 of statement arena 2) func2 saves copy1 of statement arena setup by func1 and activates copy2 3) some changes made for copy 2 4) func2 stores changed copy2 back to statenet arena and activates copy1 5) func1 store unchanged copy1 back to statemnt arena (rewrite changed copy 2 so changes become lost) and activates arena which was before.
-
- 05 Dec, 2013 1 commit
-
-
Igor Babaev authored
When marking used columns the function find_field_in_table_ref() erroneously called the walk method for the real item behind a view/derived table field with the second parameter set to TRUE. This erroneous code was introduced in 2006.
-
- 10 Oct, 2013 1 commit
-
-
Igor Babaev authored
The bug caused a memory overwrite in the function update_ref_and_keys() It happened due to a wrong value of SELECT_LEX::cond_count. This value historically was calculated by the fix_fields method. Now the logic of calling this method became too complicated and, as a result, this value is calculated not always correctly. The patch changes the way how and when the values of SELECT_LEX::cond_count and of SELECT_LEX::between_count are calculated. The new code does it just at the beginning of update_ref_and_keys().
-
- 20 Aug, 2013 1 commit
-
-
Dmitry Lenev authored
STATUS OF ROLLBACKED TRANSACTION" and bug #17054007 - "TRANSACTION IS NOT FULLY ROLLED BACK IN CASE OF INNODB DEADLOCK". The problem in the first bug report was that although deadlock involving metadata locks was reported using the same error code and message as InnoDB deadlock it didn't rollback transaction like the latter. This caused confusion to users as in some cases after ER_LOCK_DEADLOCK transaction could have been restarted immediately and in some cases rollback was required. The problem in the second bug report was that although InnoDB deadlock caused transaction rollback in all storage engines it didn't cause release of metadata locks. So concurrent DDL on the tables used in transaction was blocked until implicit or explicit COMMIT or ROLLBACK was issued in the connection which got InnoDB deadlock. The former issue has stemmed from the fact that when support for detection and reporting metadata locks deadlocks was added we erroneously assumed that InnoDB doesn't rollback transaction on deadlock but only last statement (while this is what happens on InnoDB lock timeout actually) and so didn't implement rollback of transactions on MDL deadlocks. The latter issue was caused by the fact that rollback of transaction due to deadlock is carried out by setting THD::transaction_rollback_request flag at the point where deadlock is detected and performing rollback inside of trans_rollback_stmt() call when this flag is set. And trans_rollback_stmt() is not aware of MDL locks, so no MDL locks are released. This patch solves these two problems in the following way: - In case when MDL deadlock is detect transaction rollback is requested by setting THD::transaction_rollback_request flag. - Code performing rollback of transaction if THD::transaction_rollback_request is moved out from trans_rollback_stmt(). Now we handle rollback request on the same level as we call trans_rollback_stmt() and release statement/ transaction MDL locks.
-
- 17 Apr, 2013 1 commit
-
-
Sergei Golubchik authored
with a bit of lame protection against abuse.
-
- 06 Apr, 2013 1 commit
-
-
Sergei Golubchik authored
fulltext search was initialized for all MATCH ... AGAINST items at the end of the JOIN::optimize(). But since 5.3 derived tables are initialized lazily on first use, very late in the sub_select(). Skip Item_func_match::init_search initialization if the corresponding table isn't open yet; repeat fulltext initialization for all not-yet-initialized MATCH ... AGAINST items after creating derived tables.
-
- 19 Mar, 2013 2 commits
-
-
Murthy Narkedimilli authored
-
Murthy Narkedimilli authored
-
- 01 Mar, 2013 1 commit
-
-
Michael Widenius authored
The issue was that there was that SHOW commands could open the table in the store engine, even in cases where it should not be allowed to do that (ie, the storage engines meta data for that table was under big changes). The cases where this should not be allowed are: - ALTER TABLE DISABLE KEYS - ALTER TABLE ENABLE KEYS - REPAIR TABLE - OPTIMIZE TABLE - DROP TABLE This patch adds a new mode, protected_against_usage(). If this is used then the SHOW command will wait until the table is accessable. This is implemented by re-using the already exising 'version' flag for TABLE_SHARE. It also added functions to be used to change TABLE_SHARE->version instead of changing it directly. mysql-test/r/myisam-metadata.result: Added test case mysql-test/t/myisam-metadata.test: Added test case sql/mysqld.cc: Start from refresh_version 2 as 0 and 1 are reserved. sql/sql_admin.cc: Added MYSQL_OPEN_FOR_REPAIR Updated call to wait_while_table_is_used() sql/sql_base.cc: Updated call to wait_while_table_is_used() - Allow one to specify how the table should be removed (for all commands except show or for all commands). - Don't allow one to reopen the table if one has called share->protect_against_usage() sql/sql_base.h: Added TDC_RT_REMOVE_NOT_OWN_AND_MARK_NOT_USABLE, which is used to mark that no one can reopen this table, except with MYSQL_OPEN_FOR_REPAIR . - Added MYSQL_OPEN_FOR_REPAIR - Updated prototype for wait_while_table_is_used() sql/sql_table.cc: Updated call to wait_while_table_is_used() Use MYSQL_OPEN_FOR_REPAIR for open tables that where repaired. sql/sql_truncate.cc: Updated call to wait_while_table_is_used() sql/table.cc: Use set_refresh_version() sql/table.h: Added functions to be used to change TABLE_SHARE->version instead of changing it directly
-
- 25 Feb, 2013 1 commit
-
-
Murthy Narkedimilli authored
-
- 16 Jan, 2013 1 commit
-
-
Igor Babaev authored
The original patch with the implementation of virtual columns did not support INSERT DELAYED into tables with virtual columns. This patch fixes the problem.
-
- 10 Jan, 2013 1 commit
-
-
Michael Widenius authored
Fix for MDEV-4009: main.delayed sporadically fails with "query 'REPLACE DELAYED t1 VALUES (5)' failed: 1317: Query execution was interrupted" - Fixed broadcast without a proper mutex - Don't break existing locks if we are just testing if we can get the lock mysql-test/r/create_delayed.result: Added test case for failures with INSERT DELAYED with CREATE and DROP TABLE mysql-test/t/create_delayed.test: Added test case for failures with INSERT DELAYED with CREATE and DROP TABLE sql/mdl.cc: Don't break existing locks for timeout=0 (ie, just check if there are conflicting locks). This fixed the bug that INSERT DELAYED didn't work properly with CREATE TABLE sql/sql_base.cc: One neads to hold the mutex before doing a mysql_cond_broadcast() This fixed the bug that INSERT DELAYED didn't work properly with DROP TABLE sql/sql_insert.cc: Protect setting of mysys_var->current_mutex.
-
- 21 Dec, 2012 1 commit
-
-
Roy Lyseng authored
The problem is a shift operation that is not 64-bit safe. The consequence is that used tables information for a join with 32 tables or more will be incorrect. Fixed by adding a type cast in Item_sum::update_used_tables(). Also used the opportunity to fix some other potential bugs by adding an explicit type-cast to an integer in a left-shift operation. Some of them were quite harmless, but was fixed in order to get the same signed-ness as the other operand of the operation it was used in. sql/item_cmpfunc.cc Adjusted signed-ness for some integers in left-shift. sql/item_subselect.cc Added type-cast to nesting_map (which is a 32/64 bit type, so potential bug for deeply nested queries). sql/item_sum.cc Added type-cast to nesting_map (32/64-bit type) and table_map (64-bit type). sql/opt_range.cc Added type-cast to ulonglong (which is a 64-bit type). sql/sql_base.cc Added type-cast to nesting_map (which is a 32/64-bit type). sql/sql_select.cc Added type-cast to nesting_map (32/64-bit type) and key_part_map (64-bit type). sql/strfunc.cc Changed type-cast from longlong to ulonglong, to preserve signed-ness.
-
- 11 Dec, 2012 1 commit
-
-
Dmitry Lenev authored
ROBUST AGAINST BUGS IN CALLERS". Both MDL subsystems and Table Definition Cache code assume that callers ensure that names of objects passed to them are not longer than NAME_LEN bytes. Unfortunately due to bugs in callers this assumption might be broken in some cases. As result we get nasty bugs causing buffer overruns when we construct MDL key or TDC key from object names. This patch makes TDC code more robust against such bugs by ensuring that we always checking size of result buffer when constructing TDC keys. This doesn't free its callers from ensuring that both db and table names are shorter than NAME_LEN bytes. But at least this steps prevents buffer overruns in case of bug in caller, replacing them with less harmful behavior. This is 5.1-only version of patch. This patch introduces new version of create_table_def_key() helper function which constructs TDC key without risk of result buffer overrun. Places in code that construct TDC keys were changed to use this function. Also changed rm_temporary_table() and open_new_frm() functions to avoid use of "unsafe" strmov() and strxmov() functions and use safer strnxmov() instead.
-
- 17 Dec, 2012 1 commit
-
-
Michael Widenius authored
mysql-test/r/create.result: Updated test results mysql-test/t/create.test: Updated test sql/sql_base.cc: Use push_internal_handler/pop_internal_handler to avoid errors & warnings instead of clear_error Give a warnings instead of an error for CREATE TABLE IF EXISTS sql/sql_parse.cc: Check if we failed because of table exists (can only happen from create) sql/sql_table.cc: Check if we failed because of table exists (can only happen from create)
-
- 16 Dec, 2012 2 commits
-
-
Michael Widenius authored
mysql-test/r/create.result: Added test case to show that CREATE TABLE also is not waiting if table exists. mysql-test/t/create.test: Added test case to show that CREATE TABLE also is not waiting if table exists. sql/sql_base.cc: Clear also warnings from acquire_locks if we retry.
-
Michael Widenius authored
- Added option to check_if_table_exists() to quickly check if table exists (either SHARE or .FRM) - Extended lock_table_names() to not wait for meta data locks if CREATE IF NOT EXISTS is used. mysql-test/r/create.result: New test case mysql-test/t/create.test: New test case sql/sql_base.cc: Added option to check_if_table_exists() to quickly check if table exists (either SHARE or .FRM) Extended lock_table_names() to not wait for meta data locks if CREATE IF NOT EXISTS is used. sql/sql_base.h: Updated prototype sql/sql_db.cc: Added extra argument to call to check_if_table_exists()
-
- 10 Nov, 2012 1 commit
-
-
Igor Babaev authored
If triggers are used for an insert/update/delete statement than the values of all virtual columns must be computed as any of them may be used by the triggers.
-
- 22 Sep, 2012 1 commit
-
-
Rohit Kalhans authored
QUOTING IN REPLICATION Problem: Misquoting or unquoted identifiers may lead to incorrect statements to be logged to the binary log. Fix: we use specialized functions to append quoted identifiers in the statements generated by the server.
-
- 08 Sep, 2012 1 commit
-
-
Michael Widenius authored
feature_dynamic_columns,feature_fulltext,feature_gis,feature_locale,feature_subquery,feature_timezone,feature_trigger,feature_xml Opened_views, Executed_triggers, Executed_events Added new process status 'updating status' as part of 'freeing items' mysql-test/r/features.result: Test of feature_xxx status variables mysql-test/r/mysqld--help.result: Removed duplicated 'language' variable. mysql-test/r/view.result: Test of opened_views mysql-test/suite/rpl/t/rpl_start_stop_slave.test: Write more information on failure mysql-test/t/features.test: Test of feature_xxx status variables mysql-test/t/view.test: Test of opened_views sql/event_scheduler.cc: Increment executed_events status variable sql/field.cc: Increment status variable sql/item_func.cc: Increment status variable sql/item_strfunc.cc: Increment status variable sql/item_subselect.cc: Increment status variable sql/item_xmlfunc.cc: Increment status variable sql/mysqld.cc: Add new status variables to 'show status' sql/mysqld.h: Added executed_events sql/sql_base.cc: Increment status variable sql/sql_class.h: Add new status variables sql/sql_parse.cc: Added new process status 'updating status' as part of 'freeing items' sql/sql_trigger.cc: Increment status variable sql/sys_vars.cc: Increment status variable sql/tztime.cc: Increment status variable
-
- 06 Sep, 2012 1 commit
-
-
Sergei Golubchik authored
The DELETE for emplicitly emptied MEMORY tables should be written directly to binlog.
-
- 28 Aug, 2012 1 commit
-
-
Michael Widenius authored
Split ER_NO_SUCH_TABLE into ER_NO_SUCH_TABLE and ER_NO_SUCH_TABLE_IN_ENGINE to be able to distingus if a .frm file is missing or if the table is missing in the engine. sql/handler.cc: Added ER_NO_SUCH_TABLE_IN_ENGINE sql/rpl_record.cc: Fixed wrong printf sql/share/errmsg-utf8.txt: Added ER_NO_SUCH_TABLE_IN_ENGINE sql/sp.cc: Added ER_NO_SUCH_TABLE_IN_ENGINE sql/sp_head.cc: Added ER_NO_SUCH_TABLE_IN_ENGINE sql/sql_admin.cc: Added ER_NO_SUCH_TABLE_IN_ENGINE sql/sql_base.cc: Added ER_NO_SUCH_TABLE_IN_ENGINE sql/sql_show.cc: Added ER_NO_SUCH_TABLE_IN_ENGINE sql/table.cc: Fixed typo
-
- 24 Aug, 2012 2 commits
-
-
unknown authored
Various places in the server replication code was incorrectly quoting strings, which could lead to incorrect SQL on the slave/mysqlbinlog.
-
Gopal Shankar authored
FAILED IN CHECK_LOCK_AND_ST Problem: -------- lock_tables() is supposed to invoke check_lock_and_start_stmt() for TABLE_LIST which are directly used by top level statement. TABLE_LIST->prelocking_placeholder is set only for TABLE_LIST which are used indirectly by stored programs invoked by top level statement. Hence check_lock_and_start_stmt() should have TABLE_LIST->prelocking_placeholder==false always, but it is observed that this assert fails. The failure is found during RQG test rqg_signal_resignal. Analysis: --------- open_tables() invokes open_and_process_routines() where it finds all the TABLE_LIST that belong to the routine and adds it to thd->lex->query_tables. During this process if the open_and_process_routines() fail for some reason, we are supposed to chop-off all the TABLE_LIST found during calls to open_and_process_routines(). But, in practice this is not happening. thd->lex->query_tables_own_last is supposed to point to a node in thd->lex->query_tables, which would be a first TABLE_LIST used indirectly by stored programs invoked by top level statement. This is found to be not-set correctly when we plan to chop-off TABLE_LIST's, when open_and_process_routines() failed. close_tables_for_reopen() does chop-off all the TABLE_LIST added after thd->lex->query_table_own_last. This is invoked upon error in open_and_process_routines(). This call would not work as expected as thd->lex->query_tables_own_last is not set, or is not set to correctly. Further, when open_tables() restarts the process of finding TABLE_LIST belonging to stored programs, and as the thd->lex->query_tables_own_last points to in-correct node, there is possibility of new iteration setting the thd->lex->query_tables_own_last past some old nodes that belong to stored programs, added earlier and not removed. Later when open_tables() completes, lock_tables() ends up invoking check_lock_and_start_stmt() for TABLE_LIST which belong to stored programs, which is not expected behavior and hence we hit the assert TABLE_LIST->prelocking_placeholder==false. Due to above behavior, if a user application tries to execute a SQL statement which invokes some stored function and if the lock grant on stored function fails due to a deadlock, then mysqld crashes. Fix: ---- open_tables() remembers save_query_tables_last which points to thd-lex->query_tables_last before calls to open_and_process_routines(). If there is no known thd->lex->query_tables_own_last set, we are now setting thd->lex->query_tables_own_last to save_query_tables_last. This will make sure that the call to close_tables_for_reopen() will chop-off the list correctly, in other words we now remove all the nodes added to thd->lex->query_tables, by previous calls to open_and_process_routines(). Further, it is found that the problem exists starting from 5.5, due to a code refactoring effort related to open_tables(). Hence, the fix will be pushed in 5.5, 5.6 and trunk.
-
- 21 May, 2012 1 commit
-
-
Alexey Botchkov authored
Handle the 'set read_only=1' in lighter way, than the FLUSH TABLES READ LOCK; For the transactional engines we don't wait for operations on that tables to finish. per-file comments: mysql-test/r/read_only_innodb.result MDEV-136 Non-blocking "set read_only". test result updated. mysql-test/t/read_only_innodb.test MDEV-136 Non-blocking "set read_only". test case added. sql/mysql_priv.h MDEV-136 Non-blocking "set read_only". The close_cached_tables_set_readonly() declared. sql/set_var.cc MDEV-136 Non-blocking "set read_only". Call close_cached_tables_set_readonly() for the read_only::set_var. sql/sql_base.cc MDEV-136 Non-blocking "set read_only". Parameters added to the close_cached_tables implementation, close_cached_tables_set_readonly declared. Prevent blocking on the transactional tables if the set_readonly_mode is on.
-
- 17 May, 2012 1 commit
-
-
Gopal Shankar authored
PROBLEM: Threads end-up in deadlock due to locks acquired as described below, con1: Run Query on a table. It is important that this SELECT must back-off while trying to open the t1 and enter into wait_for_condition(). The SELECT then is blocked trying to lock mysys_var->mutex which is held by con3. The very significant fact here is that mysys_var->current_mutex will still point to LOCK_open, even if LOCK_open is no longer held by con1 at this point. con2: Try dropping table used in con1 or query some table. It will hold LOCK_open and be blocked trying to lock kernel_mutex held by con4. con3: Try killing the query run by con1. It will hold THD::LOCK_thd_data belonging to con1 while trying to lock mysys_var->current_mutex belonging to con1. But current_mutex will point to LOCK_open which is held by con2. con4: Get innodb engine status It will hold kernel_mutex, trying to lock THD::LOCK_thd_data belonging to con1 which is held by con3. So while technically only con2, con3 and con4 participate in the deadlock, con1's mysys_var->current_mutex pointing to LOCK_open is a vital component of the deadlock. CYCLE = (THD::LOCK_thd_data -> LOCK_open -> kernel_mutex -> THD::LOCK_thd_data) FIX: LOCK_thd_data has responsibility of protecting, 1) thd->query, thd->query_length 2) VIO 3) thd->mysys_var (used by KILL statement and shutdown) 4) THD during thread delete. Among above responsibilities, 1), 2)and (3,4) seems to be three independent group of responsibility. If there is different LOCK owning responsibility of (3,4), the above mentioned deadlock cycle can be avoid. This fix introduces LOCK_thd_kill to handle responsibility (3,4), which eliminates the deadlock issue. Note: The problem is not found in 5.5. Introduction MDL subsystem caused metadata locking responsibility to be moved from TDC/TC to MDL subsystem. Due to this, responsibility of LOCK_open is reduced. As the use of LOCK_open is removed in open_table() and mysql_rm_table() the above mentioned CYCLE does not form. Revision ID for changes, open_table() = dlenev@mysql.com-20100727133458-m3ua9oslnx8fbbvz mysql_rm_table() = jon.hauglid@oracle.com-20101116100012-kxep9txz2fxy3nmw
-
- 15 May, 2012 1 commit
-
-
unknown authored
If we did nothing in resolving unique table conflict we should not retry (it leed to infinite loop). Now we retry (recheck) unique table check only in case if we materialized a table.
-
- 16 May, 2012 3 commits
-
-
Michael Widenius authored
Changed HA_EXTRA_NORMAL to HA_EXTRA_NOT_USED (more clean) mysql-test/suite/maria/lock.result: More extensive tests of LOCK TABLE with FLUSH and REPAIR mysql-test/suite/maria/lock.test: More extensive tests of LOCK TABLE with FLUSH and REPAIR sql/sql_admin.cc: Fix that REPAIR TABLE ... USE_FRM works with LOCK TABLES sql/sql_base.cc: Ensure that transactions are closed in ARIA when doing flush HA_EXTRA_NORMAL -> HA_EXTRA_NOT_USED Don't call extra many times for a table in close_all_tables_for_name() Added test if table_list->table as this can happen in error situations sql/sql_partition.cc: HA_EXTRA_NORMAL -> HA_EXTRA_NOT_USED sql/sql_reload.cc: Fixed comment sql/sql_table.cc: HA_EXTRA_NORMAL -> HA_EXTRA_NOT_USED sql/sql_trigger.cc: HA_EXTRA_NORMAL -> HA_EXTRA_NOT_USED sql/sql_truncate.cc: HA_EXTRA_FORCE_REOPEN -> HA_EXTRA_PREPARE_FOR_DROP for truncate, as this speeds up truncate by not having to flush the cache to disk.
-
Michael Widenius authored
mysql-test/suite/maria/maria-partitioning.result: New test case mysql-test/suite/maria/maria-partitioning.test: New test case sql/sql_base.cc: Ignore HA_EXTRA_NORMAL for wait_while_table_is_used() More DBUG sql/sql_partition.cc: Don't use HA_EXTRA_FORCE_REOPEN for wait_while_table_is_used() as the table is opened multiple times (in prep_alter_part_table) This fixes the assert in Aria where we check if table is opened multiple times if HA_EXTRA_FORCE_REOPEN is issued
-
Michael Widenius authored
Fixed bug LP:973039 - Assertion `share->in_trans == 0' failed in maria_close on DROP TABLE under LOCK - 5.5 was missing calls to ha_extra(HA_PREPARE_FOR_DROP | HA_PREPARE_FOR_RENAME); Lost in merge 5.3 -> 5.5 sql/sql_admin.cc: Updated arguments for close_all_tables_for_name sql/sql_base.h: Updated arguments for close_all_tables_for_name sql/sql_partition.cc: Updated arguments for close_all_tables_for_name sql/sql_table.cc: Updated arguments for close_all_tables_for_name Removed test of kill, as we have already called 'ha_extra(HA_PREPARE_FOR_DROP)' and the table may be inconsistent. sql/sql_trigger.cc: Updated arguments for close_all_tables_for_name sql/sql_truncate.cc: For truncate that is done with drop + recreate, signal that the table will be dropped.
-
- 20 Apr, 2012 1 commit
-
-
Andrei Elkin authored
BUG#11761686 insert_id event is not filtered. Two issues are covered. INSERT into autoincrement field which is not the first part in the composed primary key is unsafe by autoincrement logging design. The case is specific to MyISAM engine because Innodb does not allow such table definition. However no warnings and row-format logging in the MIXED mode was done, and that is fixed. Int-, Rand-, User-var log-events were not filtered along with their parent query that made possible them to screw up execution context of the following query. Fixed with deferring their execution until the parent query. ****** Bug#11754117 Post review fixes. mysql-test/suite/rpl/r/rpl_auto_increment_bug45679.result: a new result file is added. mysql-test/suite/rpl/r/rpl_filter_tables_not_exist.result: results updated. mysql-test/suite/rpl/t/rpl_auto_increment_bug45679.test: regression test for BUG#11754117-45670 is added. mysql-test/suite/rpl/t/rpl_filter_tables_not_exist.test: regression test for filtering issue of BUG#11754117 - 45670 is added. sql/log_event.cc: Logics are added for deferring and executing events associated with the Query event. sql/log_event.h: Interface to deferred events batch execution is added. sql/rpl_rli.cc: initialization for new RLI members is added. sql/rpl_rli.h: New members to RLI are added to facilitate deferred events gathering and execution control; two general character RLI cleanup methods are constructed. sql/rpl_utility.cc: Deferred_log_events methods are difined. sql/rpl_utility.h: A new class Deferred_log_events is defined to implement IRU events gathering, execution and cleanup. sql/slave.cc: Necessary changes to initialize `rli->deferred_events' and prevent deferred event deletion in the main read-exec branch. sql/sql_base.cc: A new safe-check function for multi-part pk with auto-increment is defined and deployed in lock_tables(). sql/sql_class.cc: Initialization for a new member and replication cleanups are added to THD class. sql/sql_class.h: THD class receives a new member to hold a specific execution context for slave applier. sql/sql_parse.cc: Execution of the deferred event in started prior to its parent query.
-
- 19 Apr, 2012 1 commit
-
-
unknown authored
Fixed incorrect type casting which made all fields (except very first) changes to materialized table incorrect. Saved list of view/derived table used items after expanding '*'.
-
- 06 Apr, 2012 1 commit
-
-
Igor Babaev authored
This bug happened because the function find_field_in_view formed autogenerated names of view columns without a possibility to roll them back. In some situation it could cause memory misuses reported by valgrind or even crashes.
-
- 05 Apr, 2012 1 commit
-
-
unknown authored
When a view/derived table is converted from merged to materialized the items from the used_item lists are substituted for items referring to the fields of the result of the materialization. The problem appeared with queries employing natural joins. Since the resolution of a natural join was performed only once the used_item list formed at the second execution of the query lacked the references to the fields that were used only in the equality predicates generated for the natural join.
-
- 02 Apr, 2012 1 commit
-
-
Rohit Kalhans authored
-
- 30 Mar, 2012 1 commit
-
-
Rohit Kalhans authored
Description: When the table has more than one unique or primary key, INSERT... ON DUP KEY UPDATE statement is sensitive to the order in which the storage engines checks the keys. Depending on this order, the storage engine may determine different rows to mysql, and hence mysql can update different rows on master and slave. Solution: We mark INSERT...ON DUP KEY UPDATE on a table with more than on unique key as unsafe therefore the event will be logged in row format if it is available (ROW/MIXED). If only STATEMENT format is available, a warning will be thrown. mysql-test/suite/binlog/r/binlog_unsafe.result: Updated result file mysql-test/suite/binlog/t/binlog_unsafe.test: Added test to check for warning being thrown when the unsafe statement is executed mysql-test/suite/rpl/r/rpl_known_bugs_detection.result: Updated result file sql/share/errmsg-utf8.txt: Added new warning message sql/sql_base.cc: check for tables in the query with more than one UNIQUE KEY and INSERT ON DUPLICATE KEY UPDATE, and mark such statements unsafe.
-
- 23 Mar, 2012 1 commit
-
-
Michael Widenius authored
- Don't call update_virtual_fields() if table->vfield is not set - Don't prealloc memory for in open_tables() as this is very seldom used. sql/records.cc: Don't call update_virtual_fields() if table->vfield is not set sql/sql_base.cc: Don't prealloc memory for in open_tables() as this is very seldom used. Don't call update_virtual_fields() if table->vfield is not set sql/sql_delete.cc: Don't call update_virtual_fields() if table->vfield is not set sql/sql_handler.cc: Don't call update_virtual_fields() if table->vfield is not set sql/sql_join_cache.cc: Don't call update_virtual_fields() if table->vfield is not set Move some frequent values to local variables sql/sql_table.cc: Don't call update_virtual_fields() if table->vfield is not set sql/sql_update.cc: Don't call update_virtual_fields() if table->vfield is not set sql/table.cc: Assert if update_virtual_fields is called with wrong parameters
-
- 12 Mar, 2012 1 commit
-
-
Sergey Petrunya authored
- The bug would show up - when using PS (so that we get re-execution) - the left_expr of the subquery is a reference to viewname.column_name, so that it crashes when one tries to use it without having called fix_fields for it. - when using SJ-Materialization, which makes use of sj_subq_pred->left_expr expression - The fix is to have setup_conds() fix sj_subq_pred->left_expr for semi-join nests it finds.
-