mirror of
https://github.com/MariaDB/server.git
synced 2025-01-19 13:32:33 +01:00
13 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Nirbhay Choubey
|
3435e8a515 |
MDEV-7635: Part 1
innodb_autoinc_lock_mode = 2 innodb_buffer_pool_dump_at_shutdown = ON innodb_buffer_pool_dump_pct = 25 innodb_buffer_pool_load_at_startup = ON innodb_checksum_algorithm = CRC32 innodb_file_format = Barracuda innodb_large_prefix = ON innodb_log_compressed_pages = ON innodb_purge_threads = 4 innodb_strict_mode = ON binlog_annotate_row_events = ON binlog_format = MIXED binlog-row-event-max-size = 8192 group_concat_max_len = 1M lock_wait_timeout = 86400 log_slow_admin_statements = ON log_slow_slave_statements = ON log_warnings = 2 max_allowed_packet = 16M replicate_annotate_row_events = ON slave_net_timeout = 60 sync_binlog = 1 aria_recover = BACKUP,QUICK myisam_recover_options = BACKUP,QUICK |
||
|
Sergey Vojtovich
|
8774a02364 |
MDEV-11227 - mysqlimport -l doesn't issue UNLOCK TABLES
Implementation of MDEV-7660 introduced unwanted incompatible change: modifications under LOCK TABLES with autocommit enabled are rolled back on disconnect. Previously everything was committed, because LOCK TABLES didn't adjust autocommit setting. This patch restores original behavior by reverting some changes done in MDEV-7660: - sql/sql_parse.cc: do not reset autocommit on LOCK TABLES - sql/sql_base.cc: do not set autocommit on UNLOCK TABLES - test cases: main.lock_tables_lost_commit, main.partition_explicit_prune, rpl.rpl_switch_stm_row_mixed, tokudb.nested_txn_implicit_commit, tokudb_bugs.db806 But it makes InnoDB tables under LOCK TABLES ... READ [LOCAL] not protected against DML. To restore protection some changes from WL#6671 were merged, specifically MDL_SHARED_READ_ONLY and test cases. WL#6671 merge highlights: - Not all tests merged. - In MySQL LOCK TABLES ... READ acquires MDL_SHARED_READ_ONLY for all engines, in MariaDB MDL_SHARED_READ is always acquired first and then upgraded to MDL_SHARED_READ_ONLY for InnoDB only. - The above allows us to omit MDL_SHARED_WRITE_LOW_PRIO implementation in MariaDB, which is rather useless with InnoDB. In MySQL it is needed to preserve locking behavior between low priority writes and LOCK TABLES ... READ for non-InnoDB engines (covered by sys_vars.sql_low_priority_updates_func). - Omitted HA_NO_READ_LOCAL_LOCK, we rely on lock_count() instead. - Omitted "piglets": in MariaDB stream of DML against InnoDB table may lead to concurrent LOCK TABLES ... READ starvation. - HANDLER ... OPEN acquires MDL_SHARED_READ instead of MDL_SHARED in MariaDB. - Omitted SNRW->X MDL lock upgrade for IMPORT/DISCARD TABLESPAECE under LOCK TABLES. - Omitted strong locks for views, triggers and SP under LOCK TABLES. - Omitted IX schema lock for LOCK TABLES READ. - Omitted deadlock weight juggling for LOCK TABLES. Full WL#6671 merge status: - innodb.innodb-lock: fully merged - main.alter_table: not merged due to different HANDLER solution - main.debug_sync: fully merged - main.handler_innodb: not merged due to different HANDLER solution - main.handler_myisam: not merged due to different HANDLER solution - main.innodb_mysql_lock: fully merged - main.insert_notembedded: fully merged - main.lock: not merged (due to no strong locks for views) - main.lock_multi: not merged - main.lock_sync: fully merged (partially in MDEV-7660) - main.mdl_sync: not merged - main.partition_debug_sync: not merged due to different HANDLER solution - main.status: fully merged - main.view: fully merged - perfschema.mdl_func: not merged (no such test in MariaDB) - perfschema.table_aggregate_global_2u_2t: not merged (didn't fail in MariaDB) - perfschema.table_aggregate_global_2u_3t: not merged (didn't fail in MariaDB) - perfschema.table_aggregate_global_4u_2t: not merged (didn't fail in MariaDB) - perfschema.table_aggregate_global_4u_3t: not merged (didn't fail in MariaDB) - perfschema.table_aggregate_hist_2u_2t: not merged (didn't fail in MariaDB) - perfschema.table_aggregate_hist_2u_3t: not merged (didn't fail in MariaDB) - perfschema.table_aggregate_hist_4u_2t: not merged (didn't fail in MariaDB) - perfschema.table_aggregate_hist_4u_3t: not merged (didn't fail in MariaDB) - perfschema.table_aggregate_thread_2u_2t: not merged (didn't fail in MariaDB) - perfschema.table_aggregate_thread_2u_3t: not merged (didn't fail in MariaDB) - perfschema.table_aggregate_thread_4u_2t: not merged (didn't fail in MariaDB) - perfschema.table_aggregate_thread_4u_3t: not merged (didn't fail in MariaDB) - perfschema.table_lock_aggregate_global_2u_2t: not merged (didn't fail in MariaDB) - perfschema.table_lock_aggregate_global_2u_3t: not merged (didn't fail in MariaDB) - perfschema.table_lock_aggregate_global_4u_2t: not merged (didn't fail in MariaDB) - perfschema.table_lock_aggregate_global_4u_3t: not merged (didn't fail in MariaDB) - perfschema.table_lock_aggregate_hist_2u_2t: not merged (didn't fail in MariaDB) - perfschema.table_lock_aggregate_hist_2u_3t: not merged (didn't fail in MariaDB) - perfschema.table_lock_aggregate_hist_4u_2t: not merged (didn't fail in MariaDB) - perfschema.table_lock_aggregate_hist_4u_3t: not merged (didn't fail in MariaDB) - perfschema.table_lock_aggregate_thread_2u_2t: not merged (didn't fail in MariaDB) - perfschema.table_lock_aggregate_thread_2u_3t: not merged (didn't fail in MariaDB) - perfschema.table_lock_aggregate_thread_4u_2t: not merged (didn't fail in MariaDB) - perfschema.table_lock_aggregate_thread_4u_3t: not merged (didn't fail in MariaDB) - sys_vars.sql_low_priority_updates_func: not merged - include/thr_rwlock.h: not merged, rw_pr_lock_assert_write_owner and rw_pr_lock_assert_not_write_owner are macros in MariaDB - sql/handler.h: not merged (HA_NO_READ_LOCAL_LOCK) - sql/mdl.cc: partially merged (MDL_SHARED_READ_ONLY only) - sql/mdl.h: partially merged (MDL_SHARED_READ_ONLY only) - sql/lock.cc: fully merged - sql/sp_head.cc: not merged - sql/sp_head.h: not merged - sql/sql_base.cc: partially merged (MDL_SHARED_READ_ONLY only) - sql/sql_base.h: not merged - sql/sql_class.cc: fully merged - sql/sql_class.h: fully merged - sql/sql_handler.cc: merged partially (different solution in MariaDB) - sql/sql_parse.cc: partially merged, mostly omitted low priority write part - sql/sql_reload.cc: not merged comment change - sql/sql_table.cc: not merged SNRW->X upgrade for IMPORT/DISCARD TABLESPACE - sql/sql_view.cc: not merged - sql/sql_yacc.yy: not merged (MDL_SHARED_WRITE_LOW_PRIO, MDL_SHARED_READ_ONLY) - sql/table.cc: not merged (MDL_SHARED_WRITE_LOW_PRIO) - sql/table.h: not merged (MDL_SHARED_WRITE_LOW_PRIO) - sql/trigger.cc: not merged - storage/innobase/handler/ha_innodb.cc: merged store_lock()/lock_count() changes (in MDEV-7660), didn't merge HA_NO_READ_LOCAL_LOCK - storage/innobase/handler/ha_innodb.h: fully merged in MDEV-7660 - storage/myisammrg/ha_myisammrg.cc: not merged comment change - storage/perfschema/table_helper.cc: not merged (no MDL support in MariaDB PFS) - unittest/gunit/mdl-t.cc: not merged - unittest/gunit/mdl_sync-t.cc: not merged MariaDB specific changes: - handler.heap: different HANDLER solution, MDEV-7660 - handler.innodb: different HANDLER solution, MDEV-7660 - handler.interface: different HANDLER solution, MDEV-7660 - handler.myisam: different HANDLER solution, MDEV-7660 - main.mdl_sync: MDEV-7660 specific changes - main.partition_debug_sync: removed test due to different HANDLER solution, MDEV-7660 - main.truncate_coverage: removed test due to different HANDLER solution, MDEV-7660 - mysql-test/include/mtr_warnings.sql: additional cleanup, MDEV-7660 - mysql-test/lib/v1/mtr_report.pl: additional cleanup, MDEV-7660 - plugin/metadata_lock_info/metadata_lock_info.cc: not in MySQL - sql/sql_handler.cc: MariaDB specific fix for mysql_ha_read(), MDEV-7660 |
||
|
Sergey Vojtovich
|
d665e79c5b |
MDEV-7660 - MySQL WL#6671 "Improve scalability by not using thr_lock.c locks
for InnoDB tables" Don't use thr_lock.c locks for InnoDB tables. Below is list of changes that were needed to implement this: - HANDLER OPEN acquireis MDL_SHARED_READ instead of MDL_SHARED - HANDLER READ calls external_lock() even if SE is not going to be locked by THR_LOCK - InnoDB lock wait timeouts are now honored which are much shorter by default than server lock wait timeouts (1 year vs 50 seconds) - with @@autocommit= 1 LOCK TABLES disables autocommit implicitely, though user still sees @@autocommt= 1 - the above starts implicit transaction - transactions started by LOCK TABLES are now rolled back on disconnect (previously everything was committed due to autocommit) - transactions started by LOCK TABLES are now rolled back by ROLLBACK (previously everything was committed due to autocommit) - it is now impossible to change BINLOG_FORMAT under LOCK TABLES (at least to statement) due to running transaction - LOCK TABLES WRITE is additionally handled by MDL - ...in contrast LOCK TABLES READ protection against DML is pure InnoDB - combining transactional and non-transactional tables under LOCK TABLES may cause rolled back changes in transactional table and "committed" changes in non-transactional table - user may disable innodb_table_locks, which will cause LOCK TABLES to be noop basically Removed tests for BUG#45143 and BUG#55930 which cover InnoDB + THR_LOCK. To operate properly these tests require code flow to go through THR_LOCK debug sync points, which is not the case after this patch. These tests are removed by WL#6671 as well. An alternative is to port them to different storage engine. |
||
|
Sergey Vojtovich
|
282497dd6d | MDEV-6720 - enable connection log in mysqltest by default | ||
|
Sergei Golubchik
|
86c642056a |
few fixes for test failures on windows
(and collateral changes) mysql-test/t/innodb_mysql_lock.test: change the variable from the test, not from the .opt file. one mysqld restart less. mysql-test/t/lowercase_table4.test: fix dos line endings sql/handler.cc: don't access the uninitialized variable |
||
|
Jon Olav Hauglid
|
edcd89ee1e |
Bug#11853126 RE-ENABLE CONCURRENT READS WHILE CREATING
SECONDARY INDEX IN INNODB This is a follow-up patch. This patch moves part of the new test coverage to a test file that is only run on debug builds since it used debug- only features and therefore broke the test case on release builds. |
||
|
Jon Olav Hauglid
|
9b076952ec |
Bug#11853126 RE-ENABLE CONCURRENT READS WHILE CREATING
SECONDARY INDEX IN INNODB The patches for Bug#11751388 and Bug#11784056 enabled concurrent reads while creating secondary indexes in InnoDB. However, they introduced a regression. This regression occured if ALTER TABLE failed after the index had been added, for example during the lock upgrade needed to update .FRM. If this happened, InnoDB and the server got out of sync with regards to which indexes actually existed. Therefore the patch for Bug#11815600 again disabled concurrent reads. This patch re-enables concurrent reads. The original regression is fixed by splitting the ADD INDEX operation into two parts. First the new index is created but not made active. This is done while concurrent reads are allowed. The second part of the operation makes the index active (or reverts the change). This is done after lock upgrade, which prevents the original regression. In order to implement this change, the patch changes the storage API for in-place index creation. handler::add_index() is split into two functions, handler_add_index() and handler::final_add_index(). The former for creating indexes without making them visible and the latter for commiting (i.e. making visible) new indexes or reverting the changes. Large parts of this patch were written by Marko Mäkelä. Test case added to innodb_mysql_lock.test. |
||
|
Jon Olav Hauglid
|
fc6ef378d4 |
Bug#11815600 [ERROR] INNODB COULD NOT FIND INDEX PRIMARY
KEY NO 0 FOR TABLE IN ERROR LOG With the changes made by the patches for Bug#11751388 and Bug#11784056, concurrent reads are allowed while secondary indexes are created in InnoDB. This means that the metadata lock on the affected table is not upgraded to exclusive until the .FRM is updated at the end of ALTER TABLE processing. The problem was that if this lock upgrade failed for some reason (e.g. timeout), the index information in the server and inside InnoDB would be out of sync. This would happen since the add index operation already was committed inside InnoDB but the table metadata inside the server had not been updated yet. This patch fixes the problem by (for now) reverting the effects of the patches for Bug#11751388 and Bug#11784056. Concurrent reads will now again be blocked during creation of secondary indexes in InnoDB. Test case added to innodb_mysql_lock.test. |
||
|
Jon Olav Hauglid
|
349b34b363 |
Bug #49891 View DDL breaks REPEATABLE READ
The problem was that if a query accessing a view was blocked due to conflicting locks on tables in the view definition, it would be possible for a different connection to alter the view definition before the view query completed. When the view query later resumed, it used the old view definition. This meant that if the view query was later repeated inside the same transaction, the two executions of the query would give different results, thus breaking repeatable read. (The first query used the old view definition, the second used the new view definition). This bug is no longer repeatable with the recent changes to the metadata locking subsystem (revno: 3040). The view query will no longer back-off and release the lock on the view definiton. Instead it will wait for the conflicting lock(s) to go away while keeping the view definition lock. This means that it is no longer possible for a concurrent connection to alter the view definition. Instead, any such attempt will be blocked. In the case from the bug report where the same view query was executed twice inside the same transaction, any ALTER VIEW from other connections will now be blocked until the transaction has completed (or aborted). The view queries will therefore use the same view definition and we will have repeatable read. Test case added to innodb_mysql_lock.test. This patch contains no code changes. |
||
|
Jon Olav Hauglid
|
1bfe9789ff |
Bug #53798 OPTIMIZE TABLE breaks repeatable read
The problem was that OPTMIZE TABLE was allowed to run on a table in use by a transaction in a different connection. This caused repeatable read to break. This bug was fixed by the introduction of metadata locking, WL#4284. OPTIMIZE TABLE will now be blocked until the transaction using the table, has ended. This patch contains a regression test added to innodb_mysql_lock.test and no code changes. |
||
|
Dmitry Lenev
|
eba5d30e67 |
Implement new type-of-operation-aware metadata locks.
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. mysql-test/include/handler.inc: Adjusted test case to trigger an execution path on which bug 41110 "crash with handler command when used concurrently with alter table" and bug 41112 "crash in mysql_ha_close_table/get_lock_data with alter table" were originally discovered. Left old test case which no longer triggers this execution path for the sake of coverage. Added test coverage for HANDLER SQL statements and type-aware metadata locks. Added a test for the global shared lock and HANDLER SQL. Updated tests to take into account that the old simple deadlock detection heuristics was replaced with a graph-based deadlock detector. mysql-test/r/debug_sync.result: Updated results (see debug_sync.test). mysql-test/r/handler_innodb.result: Updated results (see handler.inc test). mysql-test/r/handler_myisam.result: Updated results (see handler.inc test). mysql-test/r/innodb-lock.result: Updated results (see innodb-lock.test). mysql-test/r/innodb_mysql_lock.result: Updated results (see innodb_mysql_lock.test). mysql-test/r/lock.result: Updated results (see lock.test). mysql-test/r/lock_multi.result: Updated results (see lock_multi.test). mysql-test/r/lock_sync.result: Updated results (see lock_sync.test). mysql-test/r/mdl_sync.result: Updated results (see mdl_sync.test). mysql-test/r/sp-threads.result: SHOW PROCESSLIST output has changed due to the fact that waiting for LOCK TABLES WRITE now happens within metadata locking subsystem. mysql-test/r/truncate_coverage.result: Updated results (see truncate_coverage.test). mysql-test/suite/funcs_1/datadict/processlist_val.inc: SELECT FROM I_S.PROCESSLIST output has changed due to fact that waiting for LOCK TABLES WRITE now happens within metadata locking subsystem. mysql-test/suite/funcs_1/r/processlist_val_no_prot.result: SELECT FROM I_S.PROCESSLIST output has changed due to fact that waiting for LOCK TABLES WRITE now happens within metadata locking subsystem. mysql-test/suite/rpl/t/rpl_sp.test: Updated to a new SHOW PROCESSLIST state name. mysql-test/t/debug_sync.test: Use LOCK TABLES READ instead of LOCK TABLES WRITE as the latter no longer allows to trigger execution path involving waiting on thr_lock.c lock and therefore reaching debug sync-point covered by this test. mysql-test/t/innodb-lock.test: Adjusted test case to the fact that innodb_table_locks=0 option is no longer supported, since LOCK TABLES WRITE handles all its conflicts within MDL subsystem. mysql-test/t/innodb_mysql_lock.test: Added test for bug #37346 "innodb does not detect deadlock between update and alter table". mysql-test/t/lock.test: Added test coverage which checks the fact that we no longer support DDL under LOCK TABLES on tables which were locked implicitly. Adjusted existing test cases accordingly. mysql-test/t/lock_multi.test: Added test for bug #46272 "MySQL 5.4.4, new MDL: unnecessary deadlock". Adjusted other test cases to take into account the fact that waiting for LOCK TABLES ... WRITE now happens within MDL subsystem. mysql-test/t/lock_sync.test: Since LOCK TABLES ... WRITE now takes SNRW metadata lock for tables locked explicitly we have to implicitly lock InnoDB tables (through view) to trigger the table-level lock conflict between TL_WRITE and TL_WRITE_ALLOW_WRITE. mysql-test/t/mdl_sync.test: Added basic test coverage for type-of-operation-aware metadata locks. Also covered with tests some use cases involving HANDLER statements in which a deadlock could arise. Adjusted existing tests to take type-of-operation-aware MDL into account. mysql-test/t/multi_update.test: Update to a new SHOW PROCESSLIST state name. mysql-test/t/truncate_coverage.test: Adjusted test case after making LOCK TABLES WRITE to wait until transactions that use the table to be locked are completed. Updated to the changed name of DEBUG_SYNC point. sql/handler.cc: Global read lock functionality has been moved into a class. sql/lock.cc: Global read lock functionality has been moved into a class. Updated code to use the new MDL API. sql/mdl.cc: Introduced new type-of-operation aware metadata locks. To do this: - Changed MDL_lock to use one list for waiting requests and one list for granted requests. For each list, added a bitmap that holds information what lock types a list contains. Added a helper class MDL_lock::List to manipulate with granted and waited lists while keeping the bitmaps in sync with list contents. - Changed lock-compatibility functions to use bitmaps that define compatibility. - Introduced a graph based deadlock detector inspired by waiting_threads.c from Maria implementation. - Now that we have a deadlock detector, and no longer have a global lock to protect individual lock objects, but rather use an rw lock per object, removed redundant code for upgrade, and the global read lock. Changed the MDL API to no longer require the caller to acquire the global intention exclusive lock by means of a separate method. Removed a few more methods that became redundant. - Removed deadlock detection heuristic, it has been made obsolete by the deadlock detector. - With operation-type-aware metadata locks, MDL subsystem has become aware of potential conflicts between DDL and open transactions. This made it possible to remove calls to mysql_abort_transactions_with_shared_lock() from acquisition paths for exclusive lock and lock upgrade. Now we can simply wait for these transactions to complete without fear of deadlock. Function mysql_lock_abort() has also become unnecessary for all conflicting cases except when a DDL conflicts with a connection that has an open HANDLER. sql/mdl.h: Introduced new type-of-operation aware metadata locks. Introduced a graph based deadlock detector and supporting methods. Added comments. God rid of redundant API calls. Renamed m_lt_or_ha_sentinel to m_trans_sentinel, since now it guards the global read lock as well as LOCK TABLES and HANDLER locks. sql/mysql_priv.h: Moved the global read lock functionality into a class. Added MYSQL_OPEN_FORCE_SHARED_MDL flag which forces open_tables() to take MDL_SHARED on tables instead of metadata locks specified in the parser. We use this to allow PREPARE run concurrently in presence of LOCK TABLES ... WRITE. Added signature for find_table_for_mdl_ugprade(). sql/set_var.cc: Global read lock functionality has been moved into a class. sql/sp_head.cc: When creating TABLE_LIST elements for prelocking or system tables set the type of request for metadata lock according to the operation that will be performed on the table. sql/sql_base.cc: - Updated code to use the new MDL API. - In order to avoid locks starvation we take upgradable locks all at once. As result implicitly locked tables no longer get an upgradable lock. Consequently DDL and FLUSH TABLES for such tables is prohibited. find_write_locked_table() was replaced by find_table_for_mdl_upgrade() function. open_table() was adjusted to return TABLE instance with upgradable ticket when necessary. - We no longer wait for all locks on OT_WAIT back off action -- only on the lock that caused the wait conflict. Moreover, now we distinguish cases when we have to wait due to conflict in MDL and old version of table in TDC. - Upate mysql_notify_threads_having_share_locks() to only abort thr_lock.c waits of threads that have open HANDLERs, since lock conflicts with only these threads now can lead to deadlocks not detectable by the MDL deadlock detector. - Remove mysql_abort_transactions_with_shared_locks() which is no longer needed. sql/sql_class.cc: Global read lock functionality has been moved into a class. Re-arranged code in THD::cleanup() to simplify assert. sql/sql_class.h: Introduced class to incapsulate global read lock functionality. Now sentinel in MDL subsystem guards the global read lock as well as LOCK TABLES and HANDLER locks. Adjusted code accordingly. sql/sql_db.cc: Global read lock functionality has been moved into a class. sql/sql_delete.cc: We no longer acquire upgradable metadata locks on tables which are locked by LOCK TABLES implicitly. As result TRUNCATE TABLE is no longer allowed for such tables. Updated code to use the new MDL API. sql/sql_handler.cc: Inform MDL_context about presence of open HANDLERs. Since HANLDERs break MDL protocol by acquiring table-level lock while holding only S metadata lock on a table MDL subsystem should take special care about such contexts (Now this is the only case when mysql_lock_abort() is used). sql/sql_parse.cc: Global read lock functionality has been moved into a class. Do not take upgradable metadata locks when opening tables for CREATE TABLE SELECT as it is not necessary and limits concurrency. When initializing TABLE_LIST objects before adding them to the table list set the type of request for metadata lock according to the operation that will be performed on the table. We no longer acquire upgradable metadata locks on tables which are locked by LOCK TABLES implicitly. As result FLUSH TABLES is no longer allowed for such tables. sql/sql_prepare.cc: Use MYSQL_OPEN_FORCE_SHARED_MDL flag when opening tables during PREPARE. This allows PREPARE to run concurrently in presence of LOCK TABLES ... WRITE. sql/sql_rename.cc: Global read lock functionality has been moved into a class. sql/sql_show.cc: Updated code to use the new MDL API. sql/sql_table.cc: Global read lock functionality has been moved into a class. We no longer acquire upgradable metadata locks on tables which are locked by LOCK TABLES implicitly. As result DROP TABLE is no longer allowed for such tables. Updated code to use the new MDL API. sql/sql_trigger.cc: Global read lock functionality has been moved into a class. We no longer acquire upgradable metadata locks on tables which are locked by LOCK TABLES implicitly. As result CREATE/DROP TRIGGER is no longer allowed for such tables. Updated code to use the new MDL API. sql/sql_view.cc: Global read lock functionality has been moved into a class. Fixed results of wrong merge that led to misuse of GLR API. CREATE VIEW statement is not a commit statement. sql/table.cc: When resetting TABLE_LIST objects for PS or SP re-execution set the type of request for metadata lock according to the operation that will be performed on the table. Do the same in auxiliary function initializing metadata lock requests in a table list. sql/table.h: When initializing TABLE_LIST objects set the type of request for metadata lock according to the operation that will be performed on the table. sql/transaction.cc: Global read lock functionality has been moved into a class. |
||
|
Jon Olav Hauglid
|
0bd5741022 |
Backport of revno: 2617.68.18
Bug #42147 Concurrent DML and LOCK TABLE ... READ for InnoDB table cause warnings in errlog Concurrent execution of LOCK TABLES ... READ statement and DML statements affecting the same InnoDB table on debug builds of MySQL server might lead to "Found lock of type 6 that is write and read locked" warnings appearing in error log. The problem is that the table-level locking code allows a thread to acquire TL_READ_NO_INSERT lock on a table even if there is another thread which holds TL_WRITE_ALLOW_WRITE lock on the same table. At the same time, the locking code assumes that that such locks are incompatible (for example, see check_locks()). This doesn't lead to any problems other than warnings in error log for debug builds of server since for InnoDB tables TL_READ_NO_INSERT type of lock is only used for LOCK TABLES and for this statement InnoDB also performs its own table-level locking. Unfortunately, the table lock compatibility matrix cannot be updated to disallow TL_READ_NO_INSERT when another thread holds TL_WRITE_ALLOW_WRITE without causing starvation of LOCK TABLE READ in InnoDB under high write load. This patch therefore contains no code changes. The issue will be fixed later when LOCK TABLE READ has been updated to not use table locks. This bug will therefore be marked as "To be fixed later". Code comment in thr_lock.c expanded to clarify the issue and a test case based on the bug description added to innodb_mysql_lock.test. Note that a global suppression rule has been added to both MTR v1 and v2 for the "Found lock of type 6 that is write and read locked" warning. These suppression rules must be removed once this bug is properly fixed. |
||
|
Jon Olav Hauglid
|
5ce2421bb1 |
Backport of revno: 2617.65.1
Bug #22876 Four-way deadlock This bug was fixed as a part of Bug#989 "If DROP TABLE while there's an active transaction, wrong binlog order" A statement which would have caused circular wait will now be aborted with ER_LOCK_DEADLOCK. Test case based on bug description added to innodb_mysql_lock.test. Note that innodb_lock_wait_timeout is set to 5 mins to prevent race conditions in the test. |