summaryrefslogtreecommitdiff
path: root/sql/sql_base.h
Commit message (Collapse)AuthorAgeFilesLines
* Merge 10.3 into 10.4Marko Mäkelä2021-06-011-0/+2
|\
| * Merge 10.2 into 10.3Marko Mäkelä2021-06-011-0/+2
| |\
| | * MDEV-25576: The statement EXPLAIN running as regular statement and as ↵Dmitry Shulga2021-05-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | prepared statement produces different results for UPDATE with subquery Both EXPLAIN and EXPLAIN EXTENDED statements produce different results set in case it is run in normal way and in PS mode for the statements UPDATE/DELETE with subquery. The use case below reproduces the issue: MariaDB [test]> CREATE TABLE t1 (c1 INT KEY) ENGINE=MyISAM; Query OK, 0 rows affected (0,128 sec) MariaDB [test]> CREATE TABLE t2 (c2 INT) ENGINE=MyISAM; Query OK, 0 rows affected (0,023 sec) MariaDB [test]> CREATE TABLE t3 (c3 INT) ENGINE=MyISAM; Query OK, 0 rows affected (0,021 sec) MariaDB [test]> EXPLAIN EXTENDED UPDATE t3 SET c3 = -> ( SELECT COUNT(d1.c1) FROM ( SELECT a11.c1 FROM t1 AS a11 -> STRAIGHT_JOIN t2 AS a21 ON a21.c2 = a11.c1 JOIN t1 AS a12 -> ON a12.c1 = a11.c1 ) d1 ); +------+-------------+-------+------+---------------+------+---------+------+------+----------+--------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +------+-------------+-------+------+---------------+------+---------+------+------+----------+--------------------------------+ | 1 | PRIMARY | t3 | ALL | NULL | NULL | NULL | NULL | 0 | 100.00 | | | 2 | SUBQUERY | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | Impossible WHERE noticed after reading const tables +------+-------------+-------+------+---------------+------+---------+------+------+----------+--------------------------------+ 2 rows in set (0,002 sec) MariaDB [test]> PREPARE stmt FROM -> EXPLAIN EXTENDED UPDATE t3 SET c3 = -> ( SELECT COUNT(d1.c1) FROM ( SELECT a11.c1 FROM t1 AS a11 -> STRAIGHT_JOIN t2 AS a21 ON a21.c2 = a11.c1 JOIN t1 AS a12 -> ON a12.c1 = a11.c1 ) d1 ); Query OK, 0 rows affected (0,000 sec) Statement prepared MariaDB [test]> EXECUTE stmt; +------+-------------+-------+------+---------------+------+---------+------+------+----------+--------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +------+-------------+-------+------+---------------+------+---------+------+------+----------+--------------------------------+ | 1 | PRIMARY | t3 | ALL | NULL | NULL | NULL | NULL | 0 | 100.00 | | | 2 | SUBQUERY | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | no matching row in const table | +------+-------------+-------+------+---------------+------+---------+------+------+----------+--------------------------------+ 2 rows in set (0,000 sec) The reason by that different result sets are produced is that on execution of the statement 'EXECUTE stmt' the flag SELECT_DESCRIBE not set in the data member SELECT_LEX::options for instances of SELECT_LEX that correspond to subqueries used in the UPDTAE/DELETE statements. Initially, these flags were set on parsing the statement PREPARE stmt FROM "EXPLAIN EXTENDED UPDATE t3 SET ..." but latter they were reset before starting real execution of the parsed query during handling the statement 'EXECUTE stmt'; So, to fix the issue the functions mysql_update()/mysql_delete() have been modified to set the flag SELECT_DESCRIBE forcibly in the data member SELECT_LEX::options for the primary SELECT_LEX of the UPDATE/DELETE statement.
* | | Merge branch '10.3' into 10.4Oleksandr Byelkin2019-06-141-11/+3
|\ \ \ | |/ /
| * | Merge branch '10.2' into 10.3Oleksandr Byelkin2019-06-141-11/+3
| |\ \ | | |/
| | * Merge branch '10.1' into 10.2Oleksandr Byelkin2019-06-131-11/+3
| | |\
| | | * Merge branch '5.5' into 10.1Oleksandr Byelkin2019-06-121-11/+3
| | | |\
| | | | * MDEV-19491 update query stopped working after mariadb upgrade 10.2.23 -> 10.2.24Sergei Golubchik2019-06-011-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | as well as MDEV-19500 Update with join stopped worked if there is a call to a procedure in a trigger MDEV-19521 Update Table Fails with Trigger and Stored Function MDEV-19497 Replication stops because table not found MDEV-19527 UPDATE + JOIN + TRIGGERS = table doesn't exists error Reimplement the fix for (5d510fdbf00) MDEV-18507 can't update temporary table when joined with table with triggers on read-only instead of calling open_tables() twice, put multi-update prepare code inside open_tables() loop. Add a test for a MDL backoff-and-retry loop inside open_tables() across multi-update prepare code.
| | | | * cleanupSergei Golubchik2019-06-011-11/+1
| | | | |
* | | | | Merge branch '10.3' into 10.4Oleksandr Byelkin2019-05-191-2/+17
|\ \ \ \ \ | |/ / / /
| * | | | Merge 10.2 into 10.3Marko Mäkelä2019-05-141-1/+1
| |\ \ \ \ | | |/ / /
| | * | | Merge 10.1 into 10.2Marko Mäkelä2019-05-131-1/+1
| | |\ \ \ | | | |/ /
| | | * | Merge branch '5.5' into 10.1Vicențiu Ciorbaru2019-05-111-1/+1
| | | |\ \ | | | | |/
| | | | * Update FSF AddressVicențiu Ciorbaru2019-05-111-1/+1
| | | | | | | | | | | | | | | | | | | | * Update wrong zip-code
| * | | | Merge branch '10.2' into 10.3Oleksandr Byelkin2019-05-121-1/+16
| |\ \ \ \ | | |/ / /
| | * | | Merge branch '10.1' into 10.2Oleksandr Byelkin2019-05-041-1/+16
| | |\ \ \ | | | |/ /
| | | * | Merge branch '5.5' into 10.1Sergei Golubchik2019-04-261-1/+16
| | | |\ \ | | | | |/
| | | | * cleanupSergei Golubchik2019-04-241-1/+15
| | | | |
* | | | | stop covering_keys from being set to the same thing twiceDaniel Black2019-02-241-7/+0
| | | | |
* | | | | Added new MDL_BACKUP locks for all backup stagesMonty2018-12-091-6/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Part of MDEV-5336 Implement LOCK FOR BACKUP - Added new locks to MDL_BACKUP for all stages of backup locks and a new MDL lock needed for backup stages. - Renamed MDL_BACKUP_STMT to MDL_BACKUP_DDL - flush_tables() takes a new parameter that decides what should be flushed. - InnoDB, Aria (transactional tables with checksums), Blackhole, Federated and Federatedx tables are marked to be safe for online backup. We are using MDL_BACKUP_TRANS_DML instead of MDL_BACKUP_DML locks for these which allows any DML's to proceed for these tables during the whole backup process until BACKUP STAGE COMMIT which will block the final commit.
* | | | | Optimize flush tables with read lock (FTWRL) to not wait for select'sMonty2018-12-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Part of MDEV-5336 Implement LOCK FOR BACKUP The idea is that instead of waiting in close_cached_tables() for all tables to be closed, we instead call flush_tables() that does: - Flush not used objects in table cache to free memory - Collect all tables that are open - Call HA_EXTRA_FLUSH on the objects, to get them into "closed state" - Added HA_EXTRA_FLUSH support to archive and CSV - Added multi-user protection to HA_EXTRA_FLUSH in MyISAM and Aria The benefit compared to old code is: - FTWRL doesn't have to wait for long running read operations or open HANDLER's
* | | | | Simple cleanups (no logic changes)Monty2018-12-091-4/+0
| | | | |
* | | | | Merge 10.3 into 10.4Marko Mäkelä2018-10-051-1/+5
|\ \ \ \ \ | |/ / / /
| * | | | Merge branch '10.2' into 10.3Sergei Golubchik2018-09-281-1/+5
| |\ \ \ \ | | |/ / /
| | * | | Merge branch '10.1' into 10.2Oleksandr Byelkin2018-09-141-1/+5
| | |\ \ \ | | | |/ /
| | | * | Merge branch '11.0' into 10.1Oleksandr Byelkin2018-09-061-0/+2
| | | |\ \
| | | | * | MDEV-16465 Invalid (old?) table or database name or hang in ↵Sergei Golubchik2018-09-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ha_innobase::delete_table and log semaphore wait upon concurrent DDL with foreign keys ALTER TABLE locks the table with TL_READ_NO_INSERT, to prevent the source table modifications while it's being copied. But there's an indirect way of modifying a table, via cascade FK actions. After previous commits, an attempt to modify an FK parent table will cause FK children to be prelocked, so the table-being-altered cannot be modified by a cascade FK action, because ALTER holds a lock and prelocking will wait. But if a new FK is being added by this very ALTER, then the target table is not locked yet (it's a temporary table). So, we have to lock FK parents explicitly.
| | | * | | MDEV-15890 Strange error message if you try to FLUSH TABLES <view> after ↵Alexey Botchkov2018-09-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LOCK TABLES <view>. Check if the argument of the FLUSH TABLE is a VIEW and handle it accordingly.
* | | | | | Merge remote-tracking branch 'origin/10.3' into 10.4Alexander Barkov2018-07-251-0/+1
|\ \ \ \ \ \ | |/ / / / /
| * | | | | Merge 10.2 into 10.3Marko Mäkelä2018-07-231-0/+1
| |\ \ \ \ \ | | |/ / / /
| | * | | | MDEV-16192 Table 't' is specified twice, both as a target for 'CREATE' and...Sachin2018-07-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | as a separate source for data Actually MDEV-15867 and MDEV-16192 are same, Slave adds "or replace" to create table stmt. So create table t1 is create or replace on slave. So this bug is not because of replication, We can get this bug on general server if we manually add or replace to create query. Problem:- So if we try to create table t1 (same name as of temp table t1 ) via CREATE or replace TABLE t AS SELECT * FROM t; Since in this query we are creating table from select * from t1 , we call unique_table function to see whether if source and destination table are same. But there is one issue unique_table does not account if source table is tmp table in this case source and destination table can be same. Solution:- We will change find_dup_table to not to look for temp table if CHECK_DUP_SKIP_TEMP_TABLE flag is on.
* | | | | | MDEV-11953: support of brackets in UNION/EXCEPT/INTERSECT operationsOleksandr Byelkin2018-07-041-2/+4
|/ / / / /
* | | | | Merge branch 'github/10.2' into 10.3Sergei Golubchik2018-05-221-1/+5
|\ \ \ \ \ | |/ / / /
| * | | | Merge branch '10.1' into 10.2Sergei Golubchik2018-05-201-1/+5
| |\ \ \ \ | | |/ / /
| | * | | Merge branch '10.0' into 10.1Sergei Golubchik2018-05-191-1/+5
| | |\ \ \ | | | |/ /
| | | * | MDEV-11129 CREATE OR REPLACE TABLE t1 AS SELECT spfunc() crashes if spfunc() ↵Monty2018-05-161-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | references t1 Fixed by extending unique_table() with a flag to not allow usage of the replaced table. I also cleaned up find_dup_table() to not use goto next. I also added more comments to the code in find_dup_table()
* | | | | Merge 10.2 into 10.3Marko Mäkelä2018-05-171-2/+3
|\ \ \ \ \ | |/ / / /
| * | | | MDEV-14695: Assertion `n < m_size' failed in ↵Varun Gupta2018-05-161-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bounds_checked_array<Element_type>::operator In this issue we hit the assert because we are adding addition fields to the field JOIN::all_fields list. This is done because HEAP tables can't index BIT fields so we need to use an additional hidden field for grouping because later it will be converted to a LONG field. Original field will remain of the BIT type and will be returned. This happens when we convert DISTINCT to GROUP BY. The solution is to take into account the number of such hidden fields that would be added to the field JOIN::all_fields list while calculating the size of the ref_pointer_array.
* | | | | MDEV-15465 Server crash or ASAN heap-use-after-free in ↵Alexey Botchkov2018-05-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Item_func_match::cleanup upon using FT search with partitioning. Partition engine FT keys are implemented in such a way that the FT function's cleanup() methods use table's internals. So calling them after close_thread_tables is unsafe.
* | | | | Merge 10.2 into 10.3Marko Mäkelä2018-04-241-0/+2
|\ \ \ \ \ | |/ / / /
| * | | | Merge 10.1 into 10.2Marko Mäkelä2018-04-241-0/+2
| |\ \ \ \ | | |/ / /
| | * | | Merge 10.0 into 10.1Marko Mäkelä2018-04-241-0/+2
| | |\ \ \ | | | |/ /
| | | * | Merge branch '5.5' into 10.0Sergei Golubchik2018-04-201-0/+2
| | | |\ \ | | | | |/
| | | | * Merge branch 'mysql/5.5' into 5.5Sergei Golubchik2018-04-191-0/+2
| | | | |\
| | | | | * BUG#27216817: INNODB: FAILING ASSERTION:mysql-5.5.60Nisha Gopalakrishnan2018-02-261-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PREBUILT->TABLE->N_MYSQL_HANDLES_OPENED == 1 ANALYSIS: ========= Adding unique index to a InnoDB table which is locked as mutliple instances may trigger an InnoDB assert. When we add a primary key or an unique index, we need to drop the original table and rebuild all indexes. InnoDB expects that only the instance of the table that is being rebuilt, is open during the process. In the current scenario we have opened multiple instances of the table. This triggers an assert during table rebuild. 'Locked_tables_list' encapsulates a list of all instances of tables locked by LOCK TABLES statement. FIX: === We are now temporarily closing all the instances of the table except the one which is being altered and later reopen them via Locked_tables_list::reopen_tables().
| | | | | * Fix for bug#14188793 - "DEADLOCK CAUSED BY ALTER TABLE DOEN'T CLEARDmitry Lenev2013-08-201-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| | | | | * Bug #15954872 "MAKE MDL SUBSYSTEM AND TABLE DEFINITION CACHEDmitry Lenev2012-12-111-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 MDL and TDC code more robust against such bugs by ensuring that we always checking size of result buffer when constructing MDL and 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 these steps prevents buffer overruns in case of bug in caller, replacing them with less harmful behavior. This is 5.5-only version of patch. Changed code of MDL_key::mdl_key_init() to take into account size of buffer for the key. Introduced 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.
| | | | | * Bug #11764779 (former 57649)Jon Olav Hauglid2011-03-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FLUSH TABLES under FLUSH TABLES <list> WITH READ LOCK leads to assert failure. This assert was triggered if a statement tried up upgrade a metadata lock with an active FLUSH TABLE <list> WITH READ LOCK. The assert checks that the connection already holds a global intention exclusive metadata lock. However, FLUSH TABLE <list> WITH READ LOCK does not acquire this lock in order to be compatible with FLUSH TABLES WITH READ LOCK. Therefore any metadata lock upgrade caused the assert to be triggered. This patch fixes the problem by preventing metadata lock upgrade if the connection has an active FLUSH TABLE <list> WITH READ LOCK. ER_TABLE_NOT_LOCKED_FOR_WRITE will instead be reported to the client. Test case added to flush.test.
| | | | | * Patch that refactors global read lock implementation and fixesDmitry Lenev2010-11-111-3/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| | | | | * Remove a dead declaration.Konstantin Osipov2010-10-271-1/+0
| | | | | |
View Lorry Controller Status