- 04 Feb, 2010 3 commits
-
-
Dmitry Lenev authored
Removed local variables which became unused when we have switched to new approach for CREATE TABLE LIKE (i.e. abondoned .FRM file copying) and were causing warnings during compilation.
-
Jon Olav Hauglid authored
This was a deadlock between ALTER TABLE and another DML statement (or LOCK TABLES ... READ). ALTER TABLE would wait trying to upgrade its lock to MDL_EXCLUSIVE and the DML statement would wait trying to acquire a TL_READ_NO_INSERT table level lock. This could happen if one connection first acquired a MDL_SHARED_READ lock on a table. In another connection ALTER TABLE is then started. ALTER TABLE eventually blocks trying to upgrade to MDL_EXCLUSIVE, but while holding a TL_WRITE_ALLOW_READ table level lock. If the first connection then tries to acquire TL_READ_NO_INSERT, it will block and we have a deadlock since neither connection can proceed. This patch fixes the problem by allowing TL_READ_NO_INSERT locks to be granted if another connection holds TL_WRITE_ALLOW_READ on the same table. This will allow the DML statement to proceed such that it eventually can release its MDL lock which in turn makes ALTER TABLE able to proceed. Note that TL_READ_NO_INSERT was already partially compatible with TL_WRITE_ALLOW_READ as the latter would be granted if the former lock was held. This patch just makes the opposite true as well. Also note that since ALTER TABLE takes an upgradable MDL lock, there will be no starvation of ALTER TABLE statements by statements acquiring TL_READ or TL_READ_NO_INSERT. Test case added to lock_sync.test.
-
Dmitry Lenev authored
moving calculation of hash value when looking up MDL_lock objects in MDL_map out of critical section.
-
- 03 Feb, 2010 12 commits
-
-
Konstantin Osipov authored
-
Konstantin Osipov authored
-
Dmitry Lenev authored
type-of-operation-aware metadata locks and added a wait-for graph based deadlock detector to the MDL subsystem (this patch fixed bug #46272 "MySQL 5.4.4, new MDL: unnecessary deadlock" and bug #37346 "innodb does not detect deadlock between update and alter table"). Removed unused and redundant method.
-
Konstantin Osipov authored
-
Konstantin Osipov authored
of the TABLE_LIST instance, which did not initialize the MDL request properly. Use init_one_table() to initialize the MDL request.
-
Konstantin Osipov authored
-
Jon Olav Hauglid authored
failed in open_ltable() The problem was too restrictive asserts that enforced that open_ltable() was called without any active HANDLERs, LOCK TABLES or global read locks. However, this can happen in several cases when opening system tables. The assert would, for example, be triggered when drop function was called from a connection with active HANDLERs as this would cause open_ltable() to be called for mysql.proc. The assert could also be triggered when using table-based general log (mysql.general_log). This patch removes the asserts since they will be triggered in several legitimate cases and because the asserts are no longer relevant due to changes in how locks are released. The patch also fixes set_needs_thr_lock_abort() that before ignored its parameter and always set the member variable to TRUE. Test case added to mdl_sync.test. Thanks to Dmitry Lenev for help with this bug!
-
Konstantin Osipov authored
-
Konstantin Osipov authored
-
Konstantin Osipov authored
Post merge fixes. In sys_vars tests suite, whenever we use LOCK TABLE WRITE, adjust to lock the subject table indirecty via a view, to ensure that there the desired lock conflict in thr_lock.c is still taking place. If locked directly in LOCK TABLES list, thr_lock.c does not get involved. Adjust the thread wait state names in information_schema.processlist.
-
Dmitry Lenev authored
m_tickets.front() == m_trans_sentinel'". Debug build of server crashed due to assert failure in MDL subsystem when one tried to execute multi-table REPAIR or OPTIMIZE in autocommit=0 mode. The assert failure occured when multi-table REPAIR or OPTIMIZE started processing of second table from its table list and tried to acquire upgradable metadata lock on this table. The cause of the assert failure were MDL locks left over from processing of previous table. It turned out that in autocommit=0 mode close_thread_tables() which happens at the end of table processing doesn't release metadata locks. This fix solves problem by releasing locks explicitly using MDL_context::release_trans_locks() call.
-
Konstantin Osipov authored
-
- 02 Feb, 2010 2 commits
-
-
Konstantin Osipov authored
Fix Bug#50555 "handler commands crash server in my_hash_first()" as a post-merge fix (the new handler tests are not passing otherwise). - in hash.c, don't call calc_hash if ! my_hash_inited(). - add tests and results for the test case for Bug#50555
-
Konstantin Osipov authored
-
- 01 Feb, 2010 6 commits
-
-
Konstantin Osipov authored
-
Konstantin Osipov authored
-
Dmitry Lenev authored
which implemented new type-of-operation-aware metadata locks and added a wait-for graph based deadlock detector to the MDL subsystem (this patch fixed bug #46272 "MySQL 5.4.4, new MDL: unnecessary deadlock" and bug #37346 "innodb does not detect deadlock between update and alter table"). These hangs were caused by missing include of wait_condition.inc. This fix simply adds them.
-
Dmitry Lenev authored
caused by patch which implemented new type-of-operation-aware metadata locks and added a wait-for graph based deadlock detector to the MDL subsystem (this patch fixed bug #46272 "MySQL 5.4.4, new MDL: unnecessary deadlock" and bug #37346 "innodb does not detect deadlock between update and alter table"). Crashes were caused by a race in MDL_context::try_acquire_lock(). This method added MDL_ticket to the list of granted tickets and released lock protecting list before setting MDL_ticket::m_lock. Thus some other thread was able to see ticket without properly set m_lock member for some short period of time. If this thread called method involving this member during this period crash happened. This fix ensures that MDL_ticket::m_lock is set in all cases when ticket is added to granted/pending lists in MDL_lock.
-
Konstantin Osipov authored
in a pointer arithmetics expression).
-
Dmitry Lenev authored
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.
-
- 21 Jan, 2010 1 commit
-
-
Dmitry Lenev authored
condition variable per context instead of one mutex and one conditional variable for the whole subsystem. This should increase concurrency in this subsystem. It also opens the way for further changes which are necessary to solve such bugs as bug #46272 "MySQL 5.4.4, new MDL: unnecessary deadlock" and bug #37346 "innodb does not detect deadlock between update and alter table". Two other notable changes done by this patch: - MDL subsystem no longer implicitly acquires global intention exclusive metadata lock when per-object metadata lock is acquired. Now this has to be done by explicit calls outside of MDL subsystem. - Instead of using separate MDL_context for opening system tables/tables for purposes of I_S we now create MDL savepoint in the main context before opening tables and rollback to this savepoint after closing them. This means that it is now possible to get ER_LOCK_DEADLOCK error even not inside a transaction. This might happen in unlikely case when one runs DDL on one of system tables while also running DDL on some other tables. Cases when this ER_LOCK_DEADLOCK error is not justified will be addressed by advanced deadlock detector for MDL subsystem which we plan to implement.
-
- 20 Jan, 2010 1 commit
-
-
Jon Olav Hauglid authored
Diagnostics_area::set_ok_status at PREPARE The problem occured during processing of stored routines. Routines are loaded from mysql.proc, parsed and put into the sp cache by sp_cache_routine(). The assert occured because the return value from sp_cache_routine() was not checked for top level CALLs. This meant that any errors during sp_cache_routine() went unoticed and triggered the assert when my_ok() was later called. This is a regression introduced by the patch for Bug#30977, only visible in source trees with MDL and using debug builds of the server. This patch fixes the problem by checking the return value from sp_cache_routine() for top level CALLs and propagating any errors similar to what is done for other calls to sp_cache_routine(). No test case added.
-
- 15 Jan, 2010 3 commits
-
-
Sergey Glukhov authored
-
Jon Olav Hauglid authored
The problem was that FLUSH TABLE <table_list> would block, waiting for all tables with old versions to be removed from the table definition cache, rather than waiting for only the tables in <table_list>. This could happen if FLUSH TABLE was used in combination with LOCK TABLES. With the new MDL code, this problem is no longer repeatable. Regression test case added to lock.test. This commit contains no code changes.
-
Sergey Glukhov authored
-WL#2822 INFORMATION_SCHEMA.ROUTINES: Add missing columns -WL#2003 INFORMATION_SCHEMA: PARAMETERS view -addon for 'I_S optimization' WL
-
- 14 Jan, 2010 1 commit
-
-
Jon Olav Hauglid authored
revno: 2762 [merge] committer: Matthias Leich <mleich@mysql.com> branch nick: mysql-6.0-bugteam-push timestamp: Wed 2008-08-13 22:05:34 +0200 message: Upmerge 5.1 -> 6.0 ------------------------------------------------------------ revno: 2497.374.2 committer: Matthias Leich <mleich@mysql.com> branch nick: mysql-5.1-bugteam-push timestamp: Wed 2008-08-13 21:44:54 +0200 message: Fix for Bug#37853 Test "funcs_1.processlist_val_ps" fails in various ways + corrections of logic in poll routines + minor improvements
-
- 12 Jan, 2010 4 commits
-
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Jon Olav Hauglid authored
This was a deadlock between LOCK TABLES/CREATE DATABASE in one connection and DROP DATABASE in another. It only happened if the table locked by LOCK TABLES was in the database to be dropped. The deadlock is similar to the one in Bug#48940, but with LOCK TABLES instead of an active transaction. The order of events needed to trigger the deadlock was: 1) Connection 1 locks table db1.t1 using LOCK TABLES. It will now have a metadata lock on the table name. 2) Connection 2 issues DROP DATABASE db1. This will wait inside the MDL subsystem for the lock on db1.t1 to go away. While waiting, it will hold the LOCK_mysql_create_db mutex. 3) Connection 1 issues CREATE DATABASE (database name irrelevant). This will hang trying to lock the same mutex. Since this is the connection holding the metadata lock blocking Connection 2, we have a deadlock. This deadlock would also happen for earlier trees without MDL, but there DROP DATABASE would wait for a table to be removed from the table definition cache. This patch fixes the problem by prohibiting CREATE DATABASE in LOCK TABLES mode. In the example above, this prevents Connection 1 from hanging trying to get the LOCK_mysql_create_db mutex. Note that other commands that use LOCK_mysql_create_db (ALTER/DROP DATABASE) are already prohibited in LOCK TABLES mode. Incompatible change: CREATE DATABASE is now disallowed in LOCK TABLES mode. Test case added to schema.test.
-
Tor Didriksen authored
Bug#45523 "Objects of class base_ilist should not be copyable". Suppress the compiler-generated public copy constructor and assignment operator of class base_ilist; instead, implement move_elements_to() function which transfers ownership of elements from one list to another.
-
- 11 Jan, 2010 3 commits
-
-
Alexander Nozdrin authored
Original revision: ------------------------------------------------------------ revno: 3817 revision-id: guilhem@mysql.com-20100108092756-k0zzf4kvx9b7bh38 parent: guilhem@mysql.com-20100107101133-hrrgcdqg508runuf committer: Guilhem Bichot <guilhem@mysql.com> branch nick: mysql-6.0-codebase-bugfixing timestamp: Fri 2010-01-08 10:27:56 +0100 message: fix for BUG#50120 "Valgrind errors in any test, inside mysqltest" Problem was that as v->name[v->name_len] may be uninitialized (which is ok per se), it shouldn't be used in an if(). We remove this zero_the_char/restore_it logic by rather zero-terminating the v->name string when we create it in var_init(). ------------------------------------------------------------
-
Alexander Nozdrin authored
Original revision: ------------------------------------------------------------ revno: 3789.1.9 revision-id: serg@mysql.com-20091229134448-phe834ukzmi0k2e3 parent: serg@mysql.com-20091227081418-bgfg952gzumn1k3h committer: Sergei Golubchik <serg@mysql.com> branch nick: 6.0-codebase timestamp: Tue 2009-12-29 14:44:48 +0100 message: better fix for Bug#48758 mysqltest crashes on sys_vars.collation_server_basic in gcov builds use setenv instead of putenv ------------------------------------------------------------
-
Alexander Nozdrin authored
-
- 08 Jan, 2010 1 commit
-
-
Jon Olav Hauglid authored
INFILE". Attempts to execute an INSERT statement for a MEMORY table which invoked a trigger or called a stored function which tried to perform LOW_PRIORITY update on the table being inserted into, resulted in debug servers aborting due to an assertion failure. On non-debug servers such INSERTs failed with "Can't update table t1 in stored function/trigger because it is already used by statement which invoked this stored function/trigger" as expected. The problem was that in the above scenario TL_WRITE_CONCURRENT_INSERT is converted to TL_WRITE inside the thr_lock() function since the MEMORY engine does not support concurrent inserts. This triggered an assertion which assumed that for the same table, one thread always requests locks with higher thr_lock_type value first. When TL_WRITE_CONCURRENT_INSERT is upgraded to TL_WRITE after the locks have been sorted, this is no longer true. In this case, TL_WRITE was requested after acquiring a TL_WRITE_LOW_PRIORITY lock on the table, triggering the assert. This fix solves the problem by adjusting this assert to take this scenario into account. An alternative approach to change handler::store_locks() methods for all engines which do not support concurrent inserts in such way that TL_WRITE_CONCURRENT_INSERT is upgraded to TL_WRITE there instead, was considered too intrusive. Commit on behalf of Dmitry Lenev.
-
- 07 Jan, 2010 1 commit
-
-
Marc Alff authored
Part IV: sql instrumentation
-
- 06 Jan, 2010 2 commits
-
-
Marc Alff authored
-
Tor Didriksen authored
-