summaryrefslogtreecommitdiff
path: root/sql/sql_db.cc
Commit message (Collapse)AuthorAgeFilesLines
* Updated/added copyright headersKent Boortz2011-07-041-1/+5
|\
| * Manual merge of patch for bug#11756013 from mysql-5.1 tree.Dmitry Shulga2011-06-241-0/+3
| |\ |/ /
| * Fixed Bug#11756013 (formerly known as bug#47870):Dmitry Shulga2011-06-231-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BOGUS "THE TABLE MYSQL.PROC IS MISSING,..." There was a race condition between loading a stored routine (function/procedure/trigger) specified by fully qualified name SCHEMA_NAME.PROC_NAME and dropping the stored routine database. The problem was that there is a window for race condition when one server thread tries to load a stored routine being executed and the other thread tries to drop the stored routine schema. This condition race window exists in implementation of function mysql_change_db() called by db_load_routine() during loading of stored routine to cache. Function mysql_change_db() calls check_db_dir_existence() that might failed because specified database was dropped during concurrent execution of DROP SCHEMA statement. db_load_routine() calls mysql_change_db() with flag 'force_switch' set to 'true' value so when referenced db is not found then my_error() is not called and function mysql_change_db() returns ok. This shadows information about schema opening error in db_load_routine(). Then db_load_routine() makes attempt to parse stored routine that is failed. This makes to return error to sp_cache_routines_and_add_tables_aux() but since during error generation a call to my_error wasn't made and hence THD::main_da wasn't set we set the generic "mysql.proc table corrupt" error when running sp_cache_routines_and_add_tables_aux(). The fix is to install an error handler inside db_load_routine() for the mysql_op_change_db() call, and check later if the ER_BAD_DB_ERROR was caught.
* | Merge from mysql-5.5.10-releasehery.ramilison@oracle.com2011-03-161-2/+2
|\ \
| * | Fix for BUG#59894Guilhem Bichot2011-02-111-3/+3
| | | | | | | | | | | | | | | | | | | | | "set optimizer_switch to e or d causes invalid memory writes/valgrind warnings": due to prefix support, the argument "e" was overwritten with its full value "engine_condition_pushdown", which caused a buffer overrun. This was wrong usage of find_type(); other wrong usages are fixed here too. Please start reading with the comment of typelib.c.
* | | Bug #11765416 (former 58381)Jon Olav Hauglid2011-03-151-8/+15
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FAILED DROP DATABASE CAN BREAK STATEMENT BASED REPLICATION The first phase of DROP DATABASE is to delete the tables in the database. If deletion of one or more of the tables fail (e.g. due to a FOREIGN KEY constraint), DROP DATABASE will be aborted. However, some tables could still have been deleted. The problem was that nothing would be written to the binary log in this case, so any slaves would not delete these tables. Therefore the master and the slaves would get out of sync. This patch fixes the problem by making sure that DROP TABLE is written to the binary log for the tables that were in fact deleted by the failed DROP DATABASE statement. Test case added to binlog.binlog_database.test.
* | Manual merge from mysql-5.1-bugteam for bug#54486.Dmitry Shulga2010-12-101-11/+11
|\ \ | |/
| * Fixed bug#54486 - assert in my_seek, concurrentDmitry Shulga2010-12-101-8/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DROP/CREATE SCHEMA, CREATE TABLE, REPAIR. The cause of assert was concurrent execution of DROP DATABASE and REPAIR TABLE where first statement deleted table's file .TMD at the same time as REPAIR TABLE tried to read file details from the old file that was just removed. Additionally was fixed trouble when DROP TABLE try delete all files belong to table being dropped at the same time when REPAIR TABLE statement has just deleted .TMD file. No regression test added because this would require adding a sync point to mysys/my_redel.c. Since this bug is not present in 5.5+, adding test coverage was considered unnecessary. The patch has been verified using RQG testing.
| * Bug #46941 crash with lower_case_table_names=2 and foreign key Magne Mahre2010-10-191-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | data dictionary confusion On file systems with case insensitive file names, and lower_case_table_names set to '2', the server could crash due to a table definition cache inconsistency. This is the default setting on MacOSX, but may also be set and used on MS Windows. The bug is caused by using two different strategies for creating the hash key for the table definition cache, resulting in failure to look up an entry which is present in the cache, or failure to delete an existing entry. One strategy was to use the real table name (with case preserved), and the other to use a normalized table name (i.e a lower case version). This is manifested in two cases. One is during 'DROP DATABASE', where all known files are removed. The removal from the table definition cache is done via a generated list of TABLE_LIST with keys (wrongly) created using the case preserved name. The other is during CREATE TABLE, where the cache lookup is also (wrongly) based on the case preserved name. The fix was to use only the normalized table name when creating hash keys.
| * Bug #54360 Deadlock DROP/ALTER/CREATE DATABASE with open HANDLERJon Olav Hauglid2010-06-261-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This deadlock happened if DROP DATABASE was blocked due to an open HANDLER table from a different connection. While DROP DATABASE is blocked, it holds the LOCK_mysql_create_db mutex. This results in a deadlock if the connection with the open HANDLER table tries to execute a CREATE/ALTER/DROP DATABASE statement as they all try to acquire LOCK_mysql_create_db. This patch makes this deadlock scenario very unlikely by closing and marking for re-open all HANDLER tables for which there are pending conflicing locks, before LOCK_mysql_create_db is acquired. However, there is still a very slight possibility that a connection could access one of these HANDLER tables between closing/marking for re-open and the acquisition of LOCK_mysql_create_db. This patch is for 5.1 only, a separate and complete fix will be made for 5.5+. Test case added to schema.test.
* | Bug #57663 Concurrent statement using stored function and DROP DATABASEJon Olav Hauglid2010-11-171-131/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | breaks SBR The problem was that DROP DATABASE ignored any metadata locks on stored functions and procedures held by other connections. This made it possible for DROP DATABASE to drop functions/procedures that were in use by other connections and therefore break statement based replication. (DROP DATABASE could appear in the binlog before a statement using a dropped function/procedure.) This problem was an issue left unresolved by the patch for Bug#30977 where metadata locks for stored functions/procedures were introduced. This patch fixes the problem by making sure DROP DATABASE takes exclusive metadata locks on all stored functions/procedures to be dropped. Test case added to sp-lock.test.
* | Bug #57663 Concurrent statement using stored function and DROP DATABASEJon Olav Hauglid2010-11-161-1/+35
| | | | | | | | | | | | | | | | | | | | | | | | breaks SBR This pre-requisite patch refactors the code for dropping tables, used by DROP TABLE and DROP DATABASE. The patch moves the code for acquiring metadata locks out of mysql_rm_table_part2() and makes it the responsibility of the caller. This in preparation of changing the DROP DATABASE implementation to acquire all metadata locks before any changes are made. mysql_rm_table_part2() is renamed mysql_rm_table_no_locks() to reflect the change.
* | Bug #57663 Concurrent statement using stored function and DROP DATABASEJon Olav Hauglid2010-11-151-46/+6
| | | | | | | | | | | | | | | | | | | | breaks SBR This pre-requisite patch removes obsolete and dead code used to remove raid subdirectories and files during DROP DATABASE. Other parts of the raid code have already been removed in WL#5498 and the support for MyISAM raid tables was removed in 5.0.
* | Implement a fix for Bug#57058 -- send SERVER_QUERY_WAS_SLOW overKonstantin Osipov2010-11-121-1/+0
| | | | | | | | | | | | | | | | | | | | | | network when a query was slow. When a query is slow, sent a special flag to the client indicating this fact. Add a test case. Implement review comments.
* | Patch that refactors global read lock implementation and fixesDmitry Lenev2010-11-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bug #57006 "Deadlock between HANDLER and FLUSH TABLES WITH READ LOCK" and bug #54673 "It takes too long to get readlock for 'FLUSH TABLES WITH READ LOCK'". The first bug manifested itself as a deadlock which occurred when a connection, which had some table open through HANDLER statement, tried to update some data through DML statement while another connection tried to execute FLUSH TABLES WITH READ LOCK concurrently. What happened was that FTWRL in the second connection managed to perform first step of GRL acquisition and thus blocked all upcoming DML. After that it started to wait for table open through HANDLER statement to be flushed. When the first connection tried to execute DML it has started to wait for GRL/the second connection creating deadlock. The second bug manifested itself as starvation of FLUSH TABLES WITH READ LOCK statements in cases when there was a constant stream of concurrent DML statements (in two or more connections). This has happened because requests for protection against GRL which were acquired by DML statements were ignoring presence of pending GRL and thus the latter was starved. This patch solves both these problems by re-implementing GRL using metadata locks. Similar to the old implementation acquisition of GRL in new implementation is two-step. During the first step we block all concurrent DML and DDL statements by acquiring global S metadata lock (each DML and DDL statement acquires global IX lock for its duration). During the second step we block commits by acquiring global S lock in COMMIT namespace (commit code acquires global IX lock in this namespace). Note that unlike in old implementation acquisition of protection against GRL in DML and DDL is semi-automatic. We assume that any statement which should be blocked by GRL will either open and acquires write-lock on tables or acquires metadata locks on objects it is going to modify. For any such statement global IX metadata lock is automatically acquired for its duration. The first problem is solved because waits for GRL become visible to deadlock detector in metadata locking subsystem and thus deadlocks like one in the first bug become impossible. The second problem is solved because global S locks which are used for GRL implementation are given preference over IX locks which are acquired by concurrent DML (and we can switch to fair scheduling in future if needed). Important change: FTWRL/GRL no longer blocks DML and DDL on temporary tables. Before this patch behavior was not consistent in this respect: in some cases DML/DDL statements on temporary tables were blocked while in others they were not. Since the main use cases for FTWRL are various forms of backups and temporary tables are not preserved during backups we have opted for consistently allowing DML/DDL on temporary tables during FTWRL/GRL. Important change: This patch changes thread state names which are used when DML/DDL of FTWRL is waiting for global read lock. It is now either "Waiting for global read lock" or "Waiting for commit lock" depending on the stage on which FTWRL is. Incompatible change: To solve deadlock in events code which was exposed by this patch we have to replace LOCK_event_metadata mutex with metadata locks on events. As result we have to prohibit DDL on events under LOCK TABLES. This patch also adds extensive test coverage for interaction of DML/DDL and FTWRL. Performance of new and old global read lock implementations in sysbench tests were compared. There were no significant difference between new and old implementations.
* | merge from mysql-trunk-bugfixingJon Olav Hauglid2010-07-131-8/+7
|\ \
| * | Bug#34043: Server loops excessively in _checkchunk() when safemalloc is enabledDavi Arnaut2010-07-081-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Essentially, the problem is that safemalloc is excruciatingly slow as it checks all allocated blocks for overrun at each memory management primitive, yielding a almost exponential slowdown for the memory management functions (malloc, realloc, free). The overrun check basically consists of verifying some bytes of a block for certain magic keys, which catches some simple forms of overrun. Another minor problem is violation of aliasing rules and that its own internal list of blocks is prone to corruption. Another issue with safemalloc is rather the maintenance cost as the tool has a significant impact on the server code. Given the magnitude of memory debuggers available nowadays, especially those that are provided with the platform malloc implementation, maintenance of a in-house and largely obsolete memory debugger becomes a burden that is not worth the effort due to its slowness and lack of support for detecting more common forms of heap corruption. Since there are third-party tools that can provide the same functionality at a lower or comparable performance cost, the solution is to simply remove safemalloc. Third-party tools can provide the same functionality at a lower or comparable performance cost. The removal of safemalloc also allows a simplification of the malloc wrappers, removing quite a bit of kludge: redefinition of my_malloc, my_free and the removal of the unused second argument of my_free. Since free() always check whether the supplied pointer is null, redudant checks are also removed. Also, this patch adds unit testing for my_malloc and moves my_realloc implementation into the same file as the other memory allocation primitives.
* | | A follow-up for 5.5 version of fix for bug#54360 "Deadlock Dmitry Lenev2010-07-011-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DROP/ALTER/CREATE DATABASE with open HANDLER". Remove wait_for_condition() which became unused after database locks were replaced with MDL scoped locks. If one needs functionality provided by this call one can always use THD::enter_cond()/exit_cond() methods. Also removed an unused include from sql_db.cc and updated comment describing one of used includes to reflect current situation.
* | | A 5.5 version of the fix for Bug #54360 "Deadlock DROP/ALTER/CREATEJon Olav Hauglid2010-07-011-265/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DATABASE with open HANDLER" Remove LOCK_create_db, database name locks, and use metadata locks instead. This exposes CREATE/DROP/ALTER DATABASE statements to the graph-based deadlock detector in MDL, and paves the way for a safe, deadlock-free implementation of RENAME DATABASE. Database DDL statements will now take exclusive metadata locks on the database name, while table/view/routine DDL statements take intention exclusive locks on the database name. This prevents race conditions between database DDL and table/view/routine DDL. (e.g. DROP DATABASE with concurrent CREATE/ALTER/DROP TABLE) By adding database name locks, this patch implements WL#4450 "DDL locking: CREATE/DROP DATABASE must use database locks" and WL#4985 "DDL locking: namespace/hierarchical locks". The patch also changes code to use init_one_table() where appropriate. The new lock_table_names() function requires TABLE_LIST::db_length to be set correctly, and this is taken care of by init_one_table(). This patch also adds a simple template to help work with the mysys HASH data structure. Most of the patch was written by Konstantin Osipov.
* | | Backport from mysql-6.0-codebase of:Jon Olav Hauglid2010-06-231-0/+1
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------ revno: 3672 committer: lars-erik.bjork@sun.com branch nick: 48067-mysql-6.0-codebase-bugfixing timestamp: Mon 2009-10-26 13:51:43 +0100 message: This is a patch for bug#48067 "A temp table with the same name as an existing table, makes drop database fail" When dropping the database, mysql_rm_known_files() reads the contents of the database directory, and creates a TABLE_LIST object, for each .frm file encountered. Temporary tables, however, are not associated with any .frm file. The list of tables to drop are passed to mysql_rm_table_part2(). This method prefers temporary tables over regular tables, so if there is a temporary table with the same name as a regular, the temporary is removed, leaving the regular table intact. Regular tables are only deleted if there are no temporary tables with the same name. This fix ensures, that for all TABLE_LIST objects that are created by mysql_rm_known_files(), 'open_type' is set to 'OT_BASE_ONLY', to indicate that this is a regular table. In all cases in mysql_rm_table_part2() where we prefer a temporary table to a non-temporary table, we chek if 'open_type' equals 'OT_BASE_ONLY'.
* | Pre-requisite patch for bug #51263 "Deadlock betweenDmitry Lenev2010-05-251-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | transactional SELECT and ALTER TABLE ... REBUILD PARTITION". The goal of this patch is to decouple type of metadata lock acquired for table by open_tables() from type of table-level lock to be acquired on it. To achieve this we change approach to how we determine what type of metadata lock should be acquired on table to be open. Now instead of inferring it at open_tables() time from flags and type of table-level lock we rely on that type of metadata lock is properly set at parsing time and is not changed further.
* | WL#5030: Splitting mysql_priv.hMats Kindahl2010-04-071-0/+1
| | | | | | | | | | | | | | Adding my_global.h first in all files using NO_EMBEDDED_ACCESS_CHECKS. Correcting a merge problem resulting from a changed definition of check_some_access compared to the original patches.
* | WL#5030: Split and remove mysql_priv.hMats Kindahl2010-03-311-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch: - Moves all definitions from the mysql_priv.h file into header files for the component where the variable is defined - Creates header files if the component lacks one - Eliminates all include directives from mysql_priv.h - Eliminates all circular include cycles - Rename time.cc to sql_time.cc - Rename mysql_priv.h to sql_priv.h
* | A review comment for the fix for Bug#46672.Konstantin Osipov2010-03-131-1/+1
| | | | | | Remove unnecessary need_reopen loops.
* | Merge next-mr -> next-4284.Konstantin Osipov2010-02-061-4/+3
|\ \
| * \ Manual merge from mysql-trunk-merge.Alexander Nozdrin2010-01-311-1/+1
| |\ \ | | |/ | | | | | | | | | | | | | | | | | | | | | Conflicts: - mysql-test/suite/rpl/r/rpl_binlog_grant.result - mysql-test/suite/rpl/r/rpl_sp.result - mysql-test/suite/rpl/t/rpl_binlog_grant.test - sql/sql_parse.cc - sql/sql_table.cc - sql/sql_test.cc
| | * Fix for compiler warnings:Davi Arnaut2010-01-281-1/+1
| | | | | | | | | | | | | | | | | | | | | Rename method as to not hide a base. Reorder attributes initialization. Remove unused variable. Rework code to silence a warning due to assignment used as truth value.
| | * Backport Bug#37148 to 5.1He Zhenxing2010-01-241-9/+26
| | |
| * | Manual merge from mysql-trunk-merge.Alexander Nozdrin2010-01-301-1/+1
| |\ \ | | |/ | | | | | | | | | | | | | | | | | | | | | Conflicts: - sql/events.cc - sql/mysql_priv.h - sql/repl_failsafe.cc - sql/sql_db.cc - sql/sql_parse.cc - sql/sql_show.cc
| | * Bug#49501 Inefficient information_schema check (system collation), addonSergey Glukhov2010-01-221-1/+1
| | | | | | | | | | | | removed wrongly introduced strlen calls
| * | Manual merge from mysql-trunk-merge.Alexander Nozdrin2010-01-281-3/+2
| |\ \ | | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: - sql/event_data_objects.cc - sql/events.cc - sql/mysql_priv.h - sql/repl_failsafe.cc - sql/sql_parse.cc - sql/sql_show.cc - sql/sql_view.cc - sql/table.cc
| | * Bug#49501 Inefficient information_schema check (system collation)Sergey Glukhov2010-01-191-3/+2
| | | | | | | | | | | | added check_length optimization for I_S_NAME comparison
* | | Merge next-mr -> next-4284.Konstantin Osipov2010-02-051-10/+9
|\ \ \ | |/ /
| * | merge mysql-5.1-rep+2-delivery1 --> mysql-5.1-rpl-mergeAlfranio Correia2010-01-071-10/+9
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: Text conflict in .bzr-mysql/default.conf Text conflict in mysql-test/extra/rpl_tests/rpl_loaddata.test Text conflict in mysql-test/r/mysqlbinlog2.result Text conflict in mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result Text conflict in mysql-test/suite/binlog/r/binlog_unsafe.result Text conflict in mysql-test/suite/rpl/r/rpl_insert_id.result Text conflict in mysql-test/suite/rpl/r/rpl_loaddata.result Text conflict in mysql-test/suite/rpl/r/rpl_stm_auto_increment_bug33029.result Text conflict in mysql-test/suite/rpl/r/rpl_udf.result Text conflict in mysql-test/suite/rpl/t/rpl_slow_query_log.test Text conflict in sql/field.h Text conflict in sql/log.cc Text conflict in sql/log_event.cc Text conflict in sql/log_event_old.cc Text conflict in sql/mysql_priv.h Text conflict in sql/share/errmsg.txt Text conflict in sql/sp.cc Text conflict in sql/sql_acl.cc Text conflict in sql/sql_base.cc Text conflict in sql/sql_class.h Text conflict in sql/sql_db.cc Text conflict in sql/sql_delete.cc Text conflict in sql/sql_insert.cc Text conflict in sql/sql_lex.cc Text conflict in sql/sql_lex.h Text conflict in sql/sql_load.cc Text conflict in sql/sql_table.cc Text conflict in sql/sql_update.cc Text conflict in sql/sql_view.cc Conflict adding files to storage/innobase. Created directory. Conflict because storage/innobase is not versioned, but has versioned children. Versioned directory. Conflict adding file storage/innobase. Moved existing file to storage/innobase.moved. Conflict adding files to storage/innobase/handler. Created directory. Conflict because storage/innobase/handler is not versioned, but has versioned children. Versioned directory. Contents conflict in storage/innobase/handler/ha_innodb.cc
| | * \ mergin 5.1 -> rep+2 -> rep+3. create_table_from_dump issue will be merged on ↵Andrei Elkin2009-11-301-9/+9
| | |\ \ | | | | | | | | | | | | | | | the next step
| | * \ \ merging 5.1 main -> 5.1-rep+2 -> 5.1-rep+3; binlog_unsafe , ↵Andrei Elkin2009-11-101-3/+7
| | |\ \ \ | | | | | | | | | | | | | | | | | | rpl_mysql_upgrade fail and are under treatment
| | * | | | WL#2687 WL#5072 BUG#40278 BUG#47175Alfranio Correia2009-11-031-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Non-transactional updates that take place inside a transaction present problems for logging because they are visible to other clients before the transaction is committed, and they are not rolled back even if the transaction is rolled back. It is not always possible to log correctly in statement format when both transactional and non-transactional tables are used in the same transaction. In the current patch, we ensure that such scenario is completely safe under the ROW and MIXED modes.
* | | | | | Merge next-mr -> next-4284.Konstantin Osipov2010-02-041-9/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Cherry-pick a fix Bug#37148 from next-mr, to preserve file ids of the added files, and ensure that all the necessary changes have been pulled. Since initially Bug#37148 was null-merged into 6.0, the changeset that is now being cherry-picked was likewise null merged into next-4284. Now that Bug#37148 has been reapplied to 6.0, try to make it work with next-4284. This is also necessary to be able to pull other changes from 5.1-rep into next-4284. To resolve the merge issues use this changeset applied to 6.0: revid:jperkin@sun.com-20091216103628-ylhqf7s6yegui2t9 revno: 3776.1.1 committer: He Zhenxing <zhenxing.he@sun.com> branch nick: 6.0-codebase-bugfixing timestamp: Thu 2009-12-17 17:02:50 +0800 message: Fix merge problem with Bug#37148
* | | | | | Merge next-mr -> next-4284.Konstantin Osipov2010-02-021-6/+5
|\ \ \ \ \ \ | |/ / / / /
| * | | | | Manual merge from mysql-next-mr.Alexander Nozdrin2009-12-171-45/+71
| |\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: - mysys/charset.c - mysys/my_thr_init.c
| * \ \ \ \ \ Manual merge from mysql-trunk-merge.Alexander Nozdrin2009-12-161-6/+5
| |\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: - include/my_no_pthread.h - mysql-test/r/sp-ucs2.result - sql/log.cc - sql/sql_acl.cc - sql/sql_yacc.yy
| | * \ \ \ \ \ Manual merge of mysql-5.1-bugteam into mysql-trunk-merge.Alexey Kopytov2009-12-111-6/+5
| | |\ \ \ \ \ \ | | | | |_|_|_|/ | | | |/| | | |
| | | * | | | | Merge Bug#45520 fix from 5.0-bugteamHe Zhenxing2009-12-091-6/+5
| | | |\ \ \ \ \ | | | | |_|_|_|/ | | | |/| | | |
| | | | * | | | BUG#45520 rpl_killed_ddl fails sporadically in pb2He Zhenxing2009-12-091-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are three issues that caused rpl_killed_ddl fails sporadically in pb2: 1) thd->clear_error() was not called before create Query event if operation is executed successfully. 2) DATABASE d2 might do exist because the statement to CREATE or ALTER it was killed 3) because of bug 43353, kill the query that do DROP FUNCTION or DROP PROCEDURE can result in SP not found This patch fixed all above issues by: 1) Called thd->clear_error() if the operation succeeded. 2) Add IF EXISTS to the DROP DATABASE d2 statement 3) Temporarily disabled testing DROP FUNCTION/PROCEDURE IF EXISTS.
* | | | | | | | Merge next-mr -> next-4284.Konstantin Osipov2010-02-021-43/+69
|\ \ \ \ \ \ \ \ | | |_|_|_|/ / / | |/| | | | | |
| * | | | | | | Merge mysql-next-mr (revno 2936) --> mysql-next-mr-marcMarc Alff2009-12-111-9/+26
| |\ \ \ \ \ \ \ | | |/ / / / / /
| | * | | | | | Manual merge/pull from mysql-next-mr.Alexander Nozdrin2009-11-251-8/+8
| | |\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: - sql/sql_insert.cc
| | * | | | | | | BUG#37148 Most callers of mysql_bin_log.write ignore the return resultHe Zhenxing2009-11-211-9/+26
| | | |/ / / / / | | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the non-ndb part of the patch. The return value of mysql_bin_log.write was ignored by most callers, which may lead to inconsistent on master and slave if the transaction was committed while the binlog was not correctly written. If my_error() is call in mysql_bin_log.write, this could also lead to assertion issue if my_ok() or my_error() is called after. This fixed the problem by let the caller to check and handle the return value of mysql_bin_log.write. This patch only adresses the simple cases.
| * | | | | | | WL#2360 Performance schemaMarc Alff2009-12-091-45/+71
| | |/ / / / / | |/| | | | | | | | | | | | | | | | | | | Part III: mysys instrumentation
* | | | | | | Implement new type-of-operation-aware metadata locks.Dmitry Lenev2010-02-011-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a wait-for graph based deadlock detector to the MDL subsystem. Fixes bug #46272 "MySQL 5.4.4, new MDL: unnecessary deadlock" and bug #37346 "innodb does not detect deadlock between update and alter table". The first bug manifested itself as an unwarranted abort of a transaction with ER_LOCK_DEADLOCK error by a concurrent ALTER statement, when this transaction tried to repeat use of a table, which it has already used in a similar fashion before ALTER started. The second bug showed up as a deadlock between table-level locks and InnoDB row locks, which was "detected" only after innodb_lock_wait_timeout timeout. A transaction would start using the table and modify a few rows. Then ALTER TABLE would come in, and start copying rows into a temporary table. Eventually it would stumble on the modified records and get blocked on a row lock. The first transaction would try to do more updates, and get blocked on thr_lock.c lock. This situation of circular wait would only get resolved by a timeout. Both these bugs stemmed from inadequate solutions to the problem of deadlocks occurring between different locking subsystems. In the first case we tried to avoid deadlocks between metadata locking and table-level locking subsystems, when upgrading shared metadata lock to exclusive one. Transactions holding the shared lock on the table and waiting for some table-level lock used to be aborted too aggressively. We also allowed ALTER TABLE to start in presence of transactions that modify the subject table. ALTER TABLE acquires TL_WRITE_ALLOW_READ lock at start, and that block all writes against the table (naturally, we don't want any writes to be lost when switching the old and the new table). TL_WRITE_ALLOW_READ lock, in turn, would block the started transaction on thr_lock.c lock, should they do more updates. This, again, lead to the need to abort such transactions. The second bug occurred simply because we didn't have any mechanism to detect deadlocks between the table-level locks in thr_lock.c and row-level locks in InnoDB, other than innodb_lock_wait_timeout. This patch solves both these problems by moving lock conflicts which are causing these deadlocks into the metadata locking subsystem, thus making it possible to avoid or detect such deadlocks inside MDL. To do this we introduce new type-of-operation-aware metadata locks, which allow MDL subsystem to know not only the fact that transaction has used or is going to use some object but also what kind of operation it has carried out or going to carry out on the object. This, along with the addition of a special kind of upgradable metadata lock, allows ALTER TABLE to wait until all transactions which has updated the table to go away. This solves the second issue. Another special type of upgradable metadata lock is acquired by LOCK TABLE WRITE. This second lock type allows to solve the first issue, since abortion of table-level locks in event of DDL under LOCK TABLES becomes also unnecessary. Below follows the list of incompatible changes introduced by this patch: - From now on, ALTER TABLE and CREATE/DROP TRIGGER SQL (i.e. those statements that acquire TL_WRITE_ALLOW_READ lock) wait for all transactions which has *updated* the table to complete. - From now on, LOCK TABLES ... WRITE, REPAIR/OPTIMIZE TABLE (i.e. all statements which acquire TL_WRITE table-level lock) wait for all transaction which *updated or read* from the table to complete. As a consequence, innodb_table_locks=0 option no longer applies to LOCK TABLES ... WRITE. - DROP DATABASE, DROP TABLE, RENAME TABLE no longer abort statements or transactions which use tables being dropped or renamed, and instead wait for these transactions to complete. - Since LOCK TABLES WRITE now takes a special metadata lock, not compatible with with reads or writes against the subject table and transaction-wide, thr_lock.c deadlock avoidance algorithm that used to ensure absence of deadlocks between LOCK TABLES WRITE and other statements is no longer sufficient, even for MyISAM. The wait-for graph based deadlock detector of MDL subsystem may sometimes be necessary and is involved. This may lead to ER_LOCK_DEADLOCK error produced for multi-statement transactions even if these only use MyISAM: session 1: session 2: begin; update t1 ... lock table t2 write, t1 write; -- gets a lock on t2, blocks on t1 update t2 ... (ER_LOCK_DEADLOCK) - Finally, support of LOW_PRIORITY option for LOCK TABLES ... WRITE was abandoned. LOCK TABLE ... LOW_PRIORITY WRITE from now on has the same priority as the usual LOCK TABLE ... WRITE. SELECT HIGH PRIORITY no longer trumps LOCK TABLE ... WRITE in the wait queue. - We do not take upgradable metadata locks on implicitly locked tables. So if one has, say, a view v1 that uses table t1, and issues: LOCK TABLE v1 WRITE; FLUSH TABLE t1; -- (or just 'FLUSH TABLES'), an error is produced. In order to be able to perform DDL on a table under LOCK TABLES, the table must be locked explicitly in the LOCK TABLES list.
View Lorry Controller Status