mirror of
https://github.com/MariaDB/server.git
synced 2025-01-19 21:42:35 +01:00
65a438d87a
table causes assert failure". Attempting to use FLUSH TABLE table_list WITH READ LOCK statement for a MERGE table led to an assertion failure if one of its children was not present in the list of tables to be flushed. The problem was not visible in non-debug builds. The assertion failure was caused by the fact that in such situations FLUSH TABLES table_list WITH READ LOCK implementation tried to use (e.g. lock) such child tables without acquiring metadata lock on them. This happened because when opening tables we assumed metadata locks on all tables were already acquired earlier during statement execution and a such assumption was false for MERGE children. This patch fixes the problem by ensuring at open_tables() time that we try to acquire metadata locks on all tables to be opened. For normal tables such requests are satisfied instantly since locks are already acquired for them. For MERGE children metadata locks are acquired in normal fashion. Note that FLUSH TABLES merge_table WITH READ LOCK will lock for read both the MERGE table and its children but will flush only the MERGE table. To flush children one has to mention them in table list explicitly. This is expected behavior and it is consistent with usage patterns for this statement (e.g. in mysqlhotcopy script). mysql-test/r/flush.result: Added test case for bug #55273 "FLUSH TABLE tm WITH READ LOCK for Merge table causes assert failure". mysql-test/t/flush.test: Added test case for bug #55273 "FLUSH TABLE tm WITH READ LOCK for Merge table causes assert failure". sql/sql_base.cc: Changed lock_table_names() to support newly introduced MYSQL_OPEN_SKIP_SCOPED_MDL_LOCK flag. sql/sql_base.h: Introduced MYSQL_OPEN_SKIP_SCOPED_MDL_LOCK flag for open_tables() and lock_table_names() which allows to skip acquiring of global and schema-scope locks when SNW, SNRW or X metadata locks are acquired. sql/sql_reload.cc: Changed "FLUSH TABLES table_list WITH READ LOCK" code not to cause assert about missing metadata locks when MERGE table is flushed without one of its underlying tables. To achieve this we no longer call open_and_lock_tables() with MYSQL_OPEN_HAS_MDL_LOCK flag so this function automatically acquires metadata locks on MERGE children if such lock has not been already acquired at earlier stage. Instead we call this function with MYSQL_OPEN_SKIP_SCOPED_MDL_LOCK flag to suppress acquiring of global IX lock in order to keep FLUSH TABLES table_list WITH READ LOCK compatible with FLUSH TABLE WITH READ LOCK. Also changed implementation to use lock_table_names() function for pre-acquiring of metadata locks instead of custom code. To implement this change moved setting of open_type member for table list elements to parser. sql/sql_yacc.yy: Now we set acceptable type of table for FLUSH TABLES table_list WITH READ LOCK at parsing time instead of execution time. |
||
|---|---|---|
| .. | ||
| collections | ||
| extra | ||
| include | ||
| lib | ||
| r | ||
| std_data | ||
| suite | ||
| t | ||
| CMakeLists.txt | ||
| Makefile.am | ||
| mtr.out-of-source | ||
| mysql-stress-test.pl | ||
| mysql-test-run.pl | ||
| purify.supp | ||
| README | ||
| README.gcov | ||
| README.stress | ||
| valgrind.supp | ||
This directory contains a test suite for the MySQL daemon. To run the currently existing test cases, simply execute ./mysql-test-run in this directory. It will fire up the newly built mysqld and test it. Note that you do not have to have to do "make install", and you could actually have a co-existing MySQL installation. The tests will not conflict with it. All tests must pass. If one or more of them fail on your system, please read the following manual section for instructions on how to report the problem: http://dev.mysql.com/doc/mysql/en/mysql-test-suite.html If you want to use an already running MySQL server for specific tests, use the --extern option to mysql-test-run. Please note that in this mode, the test suite expects you to provide the names of the tests to run. For example, here is the command to run the "alias" and "analyze" tests with an external server: mysql-test-run --extern alias analyze To match your setup, you might also need to provide --socket, --user, and other relevant options. With no test cases named on the command line, mysql-test-run falls back to the normal "non-extern" behavior. The reason for this is that some tests cannot run with an external server. You can create your own test cases. To create a test case, create a new file in the t subdirectory using a text editor. The file should have a .test extension. For example: xemacs t/test_case_name.test In the file, put a set of SQL statements that create some tables, load test data, and run some queries to manipulate it. We would appreciate it if you name your test tables t1, t2, t3 ... (to not conflict too much with existing tables). Your test should begin by dropping the tables you are going to create and end by dropping them again. This ensures that you can run the test over and over again. If you are using mysqltest commands (like result file names) in your test case, you should create the result file as follows: mysql-test-run --record test_case_name or mysqltest --record < t/test_case_name.test If you only have a simple test cases consisting of SQL statements and comments, you can create the test case in one of the following ways: mysql-test-run --record test_case_name mysql test < t/test_case_name.test > r/test_case_name.result mysqltest --record --record-file=r/test_case_name.result < t/test_case_name.test When this is done, take a look at r/test_case_name.result - If the result is incorrect, you have found a bug. In this case, you should edit the test result to the correct results so that we can verify that the bug is corrected in future releases. To submit your test case, put your .test file and .result file(s) into a tar.gz archive, add a README that explains the problem, ftp the archive to ftp://support.mysql.com/pub/mysql/secret/ and send a mail to bugs@lists.mysql.com