mariadb

Commit Graph

Author	SHA1	Message	Date
Bjorn Munch	a13a8926f6	Followup test fix after 13055685: Un-needed replace_result accidentally messed up a variable used if not running parallel. Removed the bogus --replace_result	14 years ago
Jon Olav Hauglid	14df359b39	Bug #11765416 (former 58381) 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.	15 years ago
Bjorn Munch	1f9d8cd862	Bug #11762407 54999: MTR GLOBAL SUPPRESSION HIDES SQL THREAD EXECUTION UNEXPECTED ERRORS Removed the global suppression, added lots of local ones to affected tests Re-commit, now kept "Slave SQL" at start of patterns.	15 years ago
	08db5f7eb6	Bug #57666 Unclear warning with broken text in error log on INSERT DELAYED It is not necessary to support INSERT DELAYED for a single value insert, while we do not support that for multi-values insert when binlog is enabled in SBR. The lock_type is upgrade to TL_WRITE from TL_WRITE_DELAYED for INSERT DELAYED for single value insert as multi-values insert did when binlog is enabled. Then it's safe. And binlog it as INSERT without DELAYED.	15 years ago
	abb201c131	BUG#54903 BINLOG statement toggles session variables When using BINLOG statement to execute rows log events, session variables foreign_key_checks and unique_checks are changed temporarily. As each rows log event has their own special session environment and its own foreign_key_checks and unique_checks can be different from current session which executing the BINLOG statement. But these variables are not restored correctly after BINLOG statement. This problem will cause that the following statements fail or generate unexpected data. In this patch, code is added to backup and restore these two variables. So BINLOG statement will not affect current session's variables again.	15 years ago
Luis Soares	13c9cf26a6	BUG#58416: binlog.binlog_row_failure_mixing_engines fails on win x86 debug_max The windows MTR run exhibited a different test execution ordering (due to the fact that in these platforms MTR is invoked with --parallel > 1). This uncovered a bug in the aforementioned test case, which is triggered by the following conditions: 1. server is not restarted between two different tests; 2. the test before binlog.binlog_row_failure_mixing_engines issues flush logs; 3. binlog.binlog_row_failure_mixing_engines uses binlog positions to limit the output of show_binlog_events; 4. binlog.binlog_row_failure_mixing_engines does not state which binlog file to use, thence it uses a wrong binlog file with the correct position. There are two possible fixes: 1. make sure that the test start from a clean slate - binlog wise; 2. in addition to the position, also state the binary log file before sourcing show_binlog_events.inc . We go for fix #1, ie, deploy a RESET MASTER before the test is actually started.	15 years ago
Bjorn Munch	0f551def8f	Tests: many if/while expresissons simplified after 57276	15 years ago
Alfranio Correia	bf2c66d4a7	BUG#57275 binlog_cache_size affects trx- and stmt-cache and gets twice the expected memory After the WL#2687, the binlog_cache_size and max_binlog_cache_size affect both the stmt-cache and the trx-cache. This means that the resource used is twice the amount expected/defined by the user. The binlog_cache_use is incremented when the stmt-cache or the trx-cache is used and binlog_cache_disk_use is incremented when the disk space from the stmt-cache or the trx-cache is used. This behavior does not allow to distinguish which cache may be harming performance due to the extra disk accesses and needs to have its in-memory cache increased. To fix the problem, we introduced two new options and status variables related to the stmt-cache: Options: . binlog_stmt_cache_size . max_binlog_stmt_cache_size Status Variables: . binlog_stmt_cache_use . binlog_stmt_cache_disk_use So there are . binlog_cache_size that defines the size of the transactional cache for updates to transactional engines for the binary log. . binlog_stmt_cache_size that defines the size of the statement cache for updates to non-transactional engines for the binary log. . max_binlog_cache_size that sets the total size of the transactional cache. . max_binlog_stmt_cache_size that sets the total size of the statement cache. . binlog_cache_use that identifies the number of transactions that used the temporary transactional binary log cache. . binlog_cache_disk_use that identifies the number of transactions that used the temporary transactional binary log cache but that exceeded the value of binlog_cache_size. . binlog_stmt_cache_use that identifies the number of statements that used the temporary non-transactional binary log cache. . binlog_stmt_cache_disk_use that identifies the number of statements that used the temporary non-transactional binary log cache but that exceeded the value of binlog_stmt_cache_size.	15 years ago
Alfranio Correia	0be27d8f1c	BUG#56343 binlog_cache_use status is bigger than expected The binlog_cache_use is incremented twice when changes to a transactional table are committed, i.e. TC_LOG_BINLOG::log_xid calls is called. The problem happens because log_xid calls both binlog_flush_stmt_cache and binlog_flush_trx_cache without checking if such caches are empty thus unintentionally increasing the binlog_cache_use value twice. To fix the problem we avoided incrementing the binlog_cache_use if the cache is empty. We also decided to increment binlog_cache_use when the cache is truncated as the cache is used although its content is discarded and is not written to the binary log. Note that binlog_cache_use is incremented for both types of cache, transactional and non-transactional and that the behavior presented in this patch also applies to the binlog_cache_disk_use. Finally, we re-organized the code around the functions binlog_flush_trx_cache and binlog_flush_stmt_cache.	15 years ago
	0688c086a0	Bug #54579 Wrong unsafe warning for INSERT DELAYED in SBR The lock_type is upgrade to TL_WRITE from TL_WRITE_DELAYED for INSERT DELAYED when inserting multi values in one statement. It's safe. But it causes an unsafe warning in SBR. Make INSERT DELAYED safe by logging it as INSERT without DELAYED.	16 years ago
Alfranio Correia	c6d4915f3c	BUG#53452 Inconsistent behavior of binlog_direct_non_transactional_updates with temp table This patch introduces two key changes in the replication's behavior. Firstly, it reverts part of BUG#51894 which puts any update to temporary tables into the trx-cache. Now, updates to temporary tables are handled according to the type of their engines as a regular table. Secondly, an unsafe mixed statement, (i.e. a statement that access transactional table as well non-transactional or temporary table, and writes to any of them), are written into the trx-cache in order to minimize errors in the execution when the statement logging format is in use. Such changes has a direct impact on which statements are classified as unsafe statements and thus part of BUG#53259 is reverted.	16 years ago
	d3b7cd3ff2	WL#5370 Keep forward-compatibility when changing 'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour BUG#47132, BUG#47442, BUG49494, BUG#23992 and BUG#48814 will disappear automatically after the this patch. BUG#55617 is fixed by this patch too. This is the 5.5 part. It implements: - 'CREATE TABLE IF NOT EXISTS ... SELECT' statement will not insert anything and binlog anything if the table already exists. It only generate a warning that table already exists. - A couple of test cases for the behavior changing.	16 years ago
Andrei Elkin	2d91f05e88	bug#54935 applying bundle made for next-mr-bugfixing to trunk-bugfixing branch of the bug	16 years ago
Andrei Elkin	48d1c50ac1	bug#54935 applying bundle made for next-mr-bugfixing to trunk-bugfixing branch of the bug	16 years ago
Luis Soares	bf261cdb6f	BUG#54842: DROP TEMPORARY TABLE not binlogged after manual switching binlog format to ROW BUG 52616 fixed the case which the user would switch from STMT to ROW binlog format, but the server would silently ignore it. After that fix thd->is_current_stmt_binlog_format_row() reports correct value at logging time and events are logged in ROW (as expected) instead of STMT as they were previously and wrongly logged. However, the fix was only partially complete, because on disconnect, at THD cleanup, the implicit logging of temporary tables is conditionally performed. If the binlog_format==ROW and thd->is_current_stmt_binlog_format_row() is true then DROPs are not logged. Given that the user can switch from STMT to ROW, this is wrong because the server cannot tell, just by relying on the ROW binlog format, that the tables have been dropped before. This is effectively similar to the MIXED scenario when a switch from STMT to ROW is triggered. We fix this by removing this condition from close_temporary_tables.	16 years ago
Davi Arnaut	3c279d9a5a	Bug#42643: InnoDB does not support replication of TRUNCATE TABLE The problem was that TRUNCATE TABLE didn't take a exclusive lock on a table if it resorted to truncating via delete of all rows in the table. Specifically for InnoDB tables, this could break proper isolation as InnoDB ends up aborting some granted locks when truncating a table. The solution is to take a exclusive metadata lock before TRUNCATE TABLE can proceed. This guarantees that no other transaction is using the table. Incompatible change: Truncate via delete no longer fails if sql_safe_updates is activated (this was a undocumented side effect).	16 years ago
	cc05440836	Bug #49741 test files contain explicit references to bin/relay-log positions Some of the test cases reference to binlog position and these position numbers are written into result explicitly. It is difficult to maintain if log event format changes. There are a couple of cases explicit position number appears, we handle them in different ways A. 'CHANGE MASTER ...' with MASTER_LOG_POS or/and RELAY_LOG_POS options Use --replace_result to mask them. B. 'SHOW BINLOG EVENT ...' Replaced by show_binlog_events.inc or wait_for_binlog_event.inc. show_binlog_events.inc file's function is enhanced by given $binlog_file and $binlog_limit. C. 'SHOW SLAVE STATUS', 'show_slave_status.inc' and 'show_slave_status2.inc' For the test cases just care a few items in the result of 'SHOW SLAVE STATUS', only the items related to each test case are showed. 'show_slave_status.inc' is rebuild, only the given items in $status_items will be showed. 'check_slave_is_running.inc' and 'check_slave_no_error.inc' and 'check_slave_param.inc' are auxiliary files helping to show running status and error information easily.	16 years ago
Andrei Elkin	e97a0c1881	Bug #50942 mix_innodb_myisam_side_effects.test is not deterministic The test was used to fail because of UPDATE t3,t4 SET t3.a=t4.a + bug27417(1); did not prescribe the order of two row operations implied by the update. Fixed with forcing the order with adding a where condition w/o affecting the former bug fixes logics.	16 years ago
Sven Sandberg	a651824329	BUG#50670: Slave stops with error code 1644 Clarified error messages related to unsafe statements: - avoid the internal technical term "row injection" - use 'binary log' instead of 'binlog' - avoid the word 'unsafeness'	16 years ago
Konstantin Osipov	0b39c189ba	Backport of revno ## 2617.31.1, 2617.31.3, 2617.31.4, 2617.31.5, 2617.31.12, 2617.31.15, 2617.31.15, 2617.31.16, 2617.43.1 - initial changeset that introduced the fix for Bug#989 and follow up fixes for all test suite failures introduced in the initial changeset. ------------------------------------------------------------ revno: 2617.31.1 committer: Davi Arnaut <Davi.Arnaut@Sun.COM> branch nick: 4284-6.0 timestamp: Fri 2009-03-06 19:17:00 -0300 message: Bug#989: If DROP TABLE while there's an active transaction, wrong binlog order WL#4284: Transactional DDL locking Currently the MySQL server does not keep metadata locks on schema objects for the duration of a transaction, thus failing to guarantee the integrity of the schema objects being used during the transaction and to protect then from concurrent DDL operations. This also poses a problem for replication as a DDL operation might be replicated even thought there are active transactions using the object being modified. The solution is to defer the release of metadata locks until a active transaction is either committed or rolled back. This prevents other statements from modifying the table for the entire duration of the transaction. This provides commitment ordering for guaranteeing serializability across multiple transactions. - Incompatible change: If MySQL's metadata locking system encounters a lock conflict, the usual schema is to use the try and back-off technique to avoid deadlocks -- this schema consists in releasing all locks and trying to acquire them all in one go. But in a transactional context this algorithm can't be utilized as its not possible to release locks acquired during the course of the transaction without breaking the transaction commitments. To avoid deadlocks in this case, the ER_LOCK_DEADLOCK will be returned if a lock conflict is encountered during a transaction. Let's consider an example: A transaction has two statements that modify table t1, then table t2, and then commits. The first statement of the transaction will acquire a shared metadata lock on table t1, and it will be kept utill COMMIT to ensure serializability. At the moment when the second statement attempts to acquire a shared metadata lock on t2, a concurrent ALTER or DROP statement might have locked t2 exclusively. The prescription of the current locking protocol is that the acquirer of the shared lock backs off -- gives up all his current locks and retries. This implies that the entire multi-statement transaction has to be rolled back. - Incompatible change: FLUSH commands such as FLUSH PRIVILEGES and FLUSH TABLES WITH READ LOCK won't cause locked tables to be implicitly unlocked anymore.	16 years ago
Alfranio Correia	a0e606cb82	Post-fix after mysql-5.1-rep+2 --> mysql-5.1-rep+3.	16 years ago
Alfranio Correia	60d4662496	WL#2687 WL#5072 BUG#40278 BUG#47175 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.	16 years ago
	0ece5891a2	Bug#46640: output from mysqlbinlog command in 5.1 breaks replication The BINLOG statement was sharing too much code with the slave SQL thread, introduced with the patch for Bug#32407. This caused statements to be logged with the wrong server_id, the id stored inside the events of the BINLOG statement rather than the id of the running server. Fix by rearranging code a bit so that only relevant parts of the code are executed by the BINLOG statement, and the server_id of the server executing the statements will not be overrided by the server_id stored in the 'format description BINLOG statement'.	16 years ago
Alfranio Correia	b31e0c9a48	BUG#47678 Changes to n-tables that happen early in a trans. are only flushed upon commit Let - T be a transactional table and N non-transactional table. - B be begin, C commit and R rollback. - N be a statement that accesses and changes only N-tables. - T be a statement that accesses and changes only T-tables. In RBR, changes to N-tables that happen early in a transaction are not immediately flushed upon committing a statement. This behavior may, however, break consistency in the presence of concurrency since changes done to N-tables become immediately visible to other connections. To fix this problem, we do the following: . B N N T C would log - B N C B N C B T C. . B N N T R would log - B N C B N C B T R. Note that we are not preserving history from the master as we are introducing a commit that never happened. However, this seems to be more acceptable than the possibility of breaking consistency in the presence of concurrency.	16 years ago
Alfranio Correia	678eb3d66f	BUG#47287 RBR: replication diff on basic case with txn- and non-txn tables in a statement Let - T be a transactional table and N non-transactional table. - B be begin, C commit and R rollback. - M be a mixed statement, i.e. a statement that updates both T and N. - M* be a mixed statement that fails while updating either T or N. This patch restore the behavior presented in 5.1.37 for rows either produced in the RBR or MIXED modes, when a M* statement that happened early in a transaction had their changes written to the binary log outside the boundaries of the transaction and wrapped in a BEGIN/ROLLBACK. This was done to keep the slave consistent with with the master as the rollback would keep the changes on N and undo them on T. In particular, we do what follows: . B M* T C would log - B M* R B T C. Note that, we are not preserving history from the master as we are introducing a rollback that never happened. However, this seems to be more acceptable than making the slave diverge. We do not fix the following case: . B T M* C would log B T M* C. The slave will diverge as the changes on T tables that originated from the M statement are rolled back on the master but not on the slave. Unfortunately, we cannot simply rollback the transaction as this would undo any uncommitted changes on T tables. SBR is not considered in this patch because a failing statement is written to the binary along with the error code and a slave executes and then rolls back the statement when it has an associated error code, thus undoing the effects on T. In RBR and MBR, a full-fledged fix will be pushed after the WL 2687.	16 years ago
Andrei Elkin	c03549bf05	WL#342 heartbeat backporting from 6.0 code base to 5.1.	16 years ago
	f8f2362bf4	BUG #46572 DROP TEMPORARY table IF EXISTS does not have a consistent behavior in ROW mode In RBR, 'DROP TEMPORARY TABLE IF EXISTS...' statement is binlogged when the table does not exist. In fact, 'DROP TEMPORARY TABLE ...' statement should never be binlogged in RBR no matter if the table exists or not. This patch addresses this by checking whether we are dropping a temporary table or not, when building the custom drop statement.	16 years ago
Mats Kindahl	8f35f7c907	Bug #37221 : SET AUTOCOMMIT=1 does not commit binary log When setting AUTOCOMMIT=1 after starting a transaction, the binary log did not commit the outstanding transaction. The reason was that the binary log commit function saw the values of the new settings, deciding that there were nothing to commit. Fixed the problem by moving the implicit commit to before the thread option flags were changed, so that the binary log sees the old values of the flags instead of the values they will take after the statement.	16 years ago
MySQL Build Team	55b0d9772e	Backport into build-200909221805-5.1.37sp1 > ------------------------------------------------------------ > revno: 3019.1.3 > revision-id: ramil@mysql.com-20090714150729-xqv7aicsnoz6epy6 > parent: jimw@mysql.com-20090713191116-c8qxsrjagzbvbytj > committer: Ramil Kalimullin <ramil@mysql.com> > branch nick: b45998-5.1-bugteam > timestamp: Tue 2009-07-14 20:07:29 +0500 > message: > Fix for bug#45998: database crashes when running > "create as select" (innodb table) > > Problem: code constructing "CREATE TABLE..." statement > doesn't take into account that current database is not set > in some cases. That may lead to a server crash. > > Fix: check if current database is set.	16 years ago
Ramil Kalimullin	54bdf78e25	Fix for bug#45998: database crashes when running "create as select" (innodb table) Problem: code constructing "CREATE TABLE..." statement doesn't take into account that current database is not set in some cases. That may lead to a server crash. Fix: check if current database is set.	17 years ago
Mats Kindahl	e3708c231e	Bug #36763 TRUNCATE TABLE fails to replicate when stmt-based binlogging is not supported. There were two separate problems with the code, both of which are fixed with this patch: 1. An error was printed by InnoDB for TRUNCATE TABLE in statement mode when the in isolation levels READ COMMITTED and READ UNCOMMITTED since InnoDB does permit statement-based replication for DML statements. However, the TRUNCATE TABLE is not transactional, but is a DDL, and should therefore be allowed to be replicated as a statement. 2. The statement was not logged in mixed mode because of the error above, but the error was not reported to the client. This patch fixes the problem by treating TRUNCATE TABLE a DDL, that is, it is always logged as a statement and not reporting an error from InnoDB for TRUNCATE TABLE.	17 years ago
Patrick Crews	4e550c9d89	Bug#41888: Test binlog.binlog_database causing binlog_innodb to fail on Pushbuild. Added cleanup of status variables to the end of binlog_database. Re-recorded .result file to account for cleanup statement. NOTE: binlog.binlog_innodb also has had an FLUSH STATUS; statement added to it as well, but adding this cleanup as a preventative measure.	17 years ago
Mats Kindahl	43fb8633b0	Bug #38360 : BLACKHOLE replication with RBR is broken The Blackhole engine did not support row-based replication since the delete_row(), update_row(), and the index and range searching functions were not implemented. This patch adds row-based replication support for the Blackhole engine by implementing the two functions mentioned above, and making the engine pretend that it has found the correct row to delete or update when executed from the slave SQL thread by implementing index and range searching functions. It is necessary to only pretend this for the SQL thread, since a SELECT executed on the Blackhole engine will otherwise never return EOF, causing a livelock.	17 years ago
Patrick Crews	92a3b67393	Bug#37312 Make tests binlog_row_innodb_stat and binlog_stm_innodb_stat more robust Trimmed some error-prone and variable portions of the test and added 'flush status' to ensure deterministic test	17 years ago
Chad MILLER	60cca234e2	Bug#37312: Make test binlog_{row,stm}_innodb_stat more robust The size of the Innodb_buffer_pool_pages differs by one byte on row versus statement log, so neuter the last position of the stringified decimal representation. Innobase says the size isn't very important in any case. Also, split out the "mixed" format to its own file, as mtr seems to dislike having only stm and row but not mix.	18 years ago
Mats Kindahl	6461089817	Bug #38773 : DROP DATABASE cause switch to stmt-mode when there are temporary tables open When executing a DROP DATABASE statement in ROW mode and having temporary tables open at the same time, the existance of temporary tables prevent the server from switching back to row mode after temporarily switching to statement mode to handle the logging of the statement. Fixed the problem by removing the code to switch to statement mode and added code to temporarily disable the binary log while dropping the objects in the database.	18 years ago
Mats Kindahl	1bfa707a7a	Bug #38773 : DROP DATABASE cause switch to stmt-mode when there are temporary tables open When executing a DROP DATABASE statement in ROW mode and having temporary tables open at the same time, the existance of temporary tables prevent the server from switching back to row mode after temporarily switching to statement mode to handle the logging of the statement. Fixed the problem by removing the code to switch to statement mode and added code to temporarily disable the binary log while dropping the objects in the database.	18 years ago
Sven Sandberg	fc0f24812f	BUG#38068: binlog_stm_binlog fails sporadically in pushbuild Problem: binlog_stm_binlog runs INSERT DELAYED queries, and then prints the contents of the binlog. Before checking the contents of the binlog, the test waits until the rows have appeared in the table. However, this is not enough, since INSERT DELAYED does not write rows to the binlog at the same time as it writes them to the table. So there is a race. Fix: Add a FLUSH TABLES before SHOW BINLOG EVENTS. That waits until the insert_delayed thread is done.	18 years ago
msvensson@pilot.mysql.com	ae9f0285c0	Update paths Add missing drop view	18 years ago
sven@riska.(none)	4aab65ad5c	Fix pushbuild errors.	18 years ago
davi@mysql.com/endora.local	15409e87d2	Manual merge of Bug 33798	18 years ago
hezx@mail.hezx.com	1cb0eae20a	fix test failure	18 years ago
hezx@mail.hezx.com	ede9a2629b	fix failed tests	18 years ago
mkindahl@dl145h.mysql.com	d801920c56	Post-merge fixes to make tests pass.	18 years ago
mkindahl@dl145h.mysql.com	4324a5b6a3	Post-merge fixes to make binlog test suite pass.	18 years ago
msvensson@pilot.mysql.com	d918988baa	WL#4189 - dynamic configuration support - safe process - cleanups - create new suite for fedarated	18 years ago
mkindahl@dl145h.mysql.com	e0ae105055	Bug#32435: DROP DATABASE statement writes changes to mysql.proc table under RBR When replicating a DROP DATABASE statement with a database holding stored procedures, the changes to the mysql.proc table was recorded in the binary log under row-based replication. With this patch, the thread uses statement-logging format for the duration of the DROP DATABASE statement. The logging format is (already) reset at the end of the statement, so no additional code for resetting the logging format is necessary.	18 years ago
istruewing@stella.local	0605274155	Bug#26379 - Combination of FLUSH TABLE and REPAIR TABLE corrupts a MERGE table Bug 26867 - LOCK TABLES + REPAIR + merge table result in memory/cpu hogging Bug 26377 - Deadlock with MERGE and FLUSH TABLE Bug 25038 - Waiting TRUNCATE Bug 25700 - merge base tables get corrupted by optimize/analyze/repair table Bug 30275 - Merge tables: flush tables or unlock tables causes server to crash Bug 19627 - temporary merge table locking Bug 27660 - Falcon: merge table possible Bug 30273 - merge tables: Can't lock file (errno: 155) The problems were: Bug 26379 - Combination of FLUSH TABLE and REPAIR TABLE corrupts a MERGE table 1. A thread trying to lock a MERGE table performs busy waiting while REPAIR TABLE or a similar table administration task is ongoing on one or more of its MyISAM tables. 2. A thread trying to lock a MERGE table performs busy waiting until all threads that did REPAIR TABLE or similar table administration tasks on one or more of its MyISAM tables in LOCK TABLES segments do UNLOCK TABLES. The difference against problem #1 is that the busy waiting takes place after the administration task. It is terminated by UNLOCK TABLES only. 3. Two FLUSH TABLES within a LOCK TABLES segment can invalidate the lock. This does not require a MERGE table. The first FLUSH TABLES can be replaced by any statement that requires other threads to reopen the table. In 5.0 and 5.1 a single FLUSH TABLES can provoke the problem. Bug 26867 - LOCK TABLES + REPAIR + merge table result in memory/cpu hogging Trying DML on a MERGE table, which has a child locked and repaired by another thread, made an infinite loop in the server. Bug 26377 - Deadlock with MERGE and FLUSH TABLE Locking a MERGE table and its children in parent-child order and flushing the child deadlocked the server. Bug 25038 - Waiting TRUNCATE Truncating a MERGE child, while the MERGE table was in use, let the truncate fail instead of waiting for the table to become free. Bug 25700 - merge base tables get corrupted by optimize/analyze/repair table Repairing a child of an open MERGE table corrupted the child. It was necessary to FLUSH the child first. Bug 30275 - Merge tables: flush tables or unlock tables causes server to crash Flushing and optimizing locked MERGE children crashed the server. Bug 19627 - temporary merge table locking Use of a temporary MERGE table with non-temporary children could corrupt the children. Temporary tables are never locked. So we do now prohibit non-temporary chidlren of a temporary MERGE table. Bug 27660 - Falcon: merge table possible It was possible to create a MERGE table with non-MyISAM children. Bug 30273 - merge tables: Can't lock file (errno: 155) This was a Windows-only bug. Table administration statements sometimes failed with "Can't lock file (errno: 155)". These bugs are fixed by a new implementation of MERGE table open. When opening a MERGE table in open_tables() we do now add the child tables to the list of tables to be opened by open_tables() (the "query_list"). The children are not opened in the handler at this stage. After opening the parent, open_tables() opens each child from the now extended query_list. When the last child is opened, we remove the children from the query_list again and attach the children to the parent. This behaves similar to the old open. However it does not open the MyISAM tables directly, but grabs them from the already open children. When closing a MERGE table in close_thread_table() we detach the children only. Closing of the children is done implicitly because they are in thd->open_tables. For more detail see the comment at the top of ha_myisammrg.cc. Changed from open_ltable() to open_and_lock_tables() in all places that can be relevant for MERGE tables. The latter can handle tables added to the list on the fly. When open_ltable() was used in a loop over a list of tables, the list must be temporarily terminated after every table for open_and_lock_tables(). table_list->required_type is set to FRMTYPE_TABLE to avoid open of special tables. Handling of derived tables is suppressed. These details are handled by the new function open_n_lock_single_table(), which has nearly the same signature as open_ltable() and can replace it in most cases. In reopen_tables() some of the tables open by a thread can be closed and reopened. When a MERGE child is affected, the parent must be closed and reopened too. Closing of the parent is forced before the first child is closed. Reopen happens in the order of thd->open_tables. MERGE parents do not attach their children automatically at open. This is done after all tables are reopened. So all children are open when attaching them. Special lock handling like mysql_lock_abort() or mysql_lock_remove() needs to be suppressed for MERGE children or forwarded to the parent. This depends on the situation. In loops over all open tables one suppresses child lock handling. When a single table is touched, forwarding is done. Behavioral changes: =================== This patch changes the behavior of temporary MERGE tables. Temporary MERGE must have temporary children. The old behavior was wrong. A temporary table is not locked. Hence even non-temporary children were not locked. See Bug 19627 - temporary merge table locking. You cannot change the union list of a non-temporary MERGE table when LOCK TABLES is in effect. The following does not work: CREATE TABLE m1 ... ENGINE=MRG_MYISAM ...; LOCK TABLES t1 WRITE, t2 WRITE, m1 WRITE; ALTER TABLE m1 ... UNION=(t1,t2) ...; However, you can do this with a temporary MERGE table. You cannot create a MERGE table with CREATE ... SELECT, neither as a temporary MERGE table, nor as a non-temporary MERGE table. CREATE TABLE m1 ... ENGINE=MRG_MYISAM ... SELECT ...; Gives error message: table is not BASE TABLE.	18 years ago
aelkin/elkin@koti.dsl.inet.fi	8f7550ecad	manual merge for bug_29136, bug#29309.	18 years ago
aelkin@dl145j.mysql.com	0c153419ce	Merge: bug@27417,23333 and bug#28960 tests with 5.1	19 years ago

1 2 3 4

165 Commits (5f4c6942bfc6b88a8e934decfcf2f991bce6628e)