mariadb

Commit Graph

Author	SHA1	Message	Date
Pavan Naik	1c0122c5c1	BUG#16321920 : CREATE A SEPARATE INNODB_ZIP TEST SUITE Fix : ------- Created separate suites called innodb_zip ans i_innodb_zip that contain all compression tests. Running the new suites with following compression-related parameters : * innodb_compression_level = {1/9} * innodb_log_compressed_pages = {ON/OFF}	12 years ago
Nuno Carvalho	3399194cef	WL#7266: Dump-thread additional concurrency tests This worklog aims at testing the two following scenarios: 1) Whenever the mysql_binlog_send method (dump thread) reaches the end of file when reading events from the binlog, before checking if it should wait for more events, there was a test to check if the file being read was still active, i.e, it was the last known binlog. However, it was possible that something was written to the binary log and then a rotation would happen, after EOF was detected and before the check for active was performed. In this case, the end of the binary log would not be read by the dump thread, and this would cause the slave to lose updates. This test verifies that the problem has been fixed. It waits during this window while forcing a rotation in the binlog. 2) Verify dump thread can send events in active file, correctly after encountering an IO error.	12 years ago
Mattias Jonsson	6ca4be9c03	Bug#14621190: HA_INNOBASE::INDEX_NEXT SKIPS A RECORD IF PREVIOUS INDEX_READ_MAP HAD NO MATCH If index_read_map is called for exact search and no matching records exists it will position the cursor on the next record, but still having the relative position to BTR_PCUR_ON. This will make a call for index_next to read yet another next record, instead of returning the record the cursor points to. Fixed by setting pcur->rel_pos = BTR_PCUR_BEFORE if an exact [prefix] search is done, but failed. Also avoids optimistic restoration if rel_pos != BTR_PCUR_ON, since btr_cur may be different than old_rec. rb#3324, approved by Marko and Jimmy	12 years ago
Shivji Kumar Jha	d4011a6144	BUG#16580366- MTR TESTS FAILING SPORADICALLY ON PB2 (5.5, 5.6 AND 5.7) DURING INNODB RECOVERY Problem: ======= The connection 'master' is dropped by mysqltest after rpl_end.inc. At this point, dropping temporary tables at the connection 'master' are not synced at slave. So, the temporary tables replicated from master remain on slave leading to an inconsistent close of the test. The following test thus complains about the presence of temporary table(s) left over from the previous test. Fix: === - Put explicit drop commands in replication tests so that the temporary tables are dropped at slave as well. - Added the check for Slave_open_temp_tables in mtr_check.sql to warn about the remaining temporary table, if any, at the close of a test.	12 years ago
Mattias Jonsson	b7232337e9	post-push fix for bug#53947 test change only. Removed --source include/not_windows_embedded.inc which was added due to that bug.	12 years ago
Libing Song	aff9f26290	Bug#17402313 DUMP THREAD SENDS SOME EVENTS MORE THAN ONCE Postfix, suppress the new warning generated by the bug's fix.	12 years ago
Venkatesh Duggirala	eb152f86af	BUG#16290902 DROP TEMP TABLE IF EXISTS CAN CAUSE POINT IN TIME RECOVERY FAILURE ON SLAVES Problem: DROP TEMP TABLE IF EXISTS commands can cause point in time recovery (re-applying binlog) failures. Analyses: In RBR, 'DROP TEMPORARY TABLE' commands are always binlogged by adding 'IF EXISTS' clauses. Also, the slave SQL thread will not check replicate.* filter rules for "DROP TEMPORARY TABLE IF EXISTS" queries. If log-slave-updates is enabled on slave, these queries will be binlogged in the format of "USE `db`; DROP TEMPORARY TABLE IF EXISTS `t1`;" irrespective of filtering rules and irrespective of the `db` existence. When users try to recover slave from it's own binlog, use `db` command might fail if `db` is not present on slave. Fix: At the time of writing the 'DROP TEMPORARY TABLE IF EXISTS' query into the binlog, 'use `db`' will not be present and the table name in the query will be a fully qualified table name. Eg: 'USE `db`; DROP TEMPORARY TABLE IF EXISTS `t1`;' will be logged as 'DROP TEMPORARY TABLE IF EXISTS `db`.`t1`;'.	13 years ago
Astha Pareek	c38ddd971e	BUG#16295518 - SYS_VARS.RPL_INIT_SLAVE_FUNC IS FAILING ON MYSQL-5.1 BUG#12535301- SYS_VARS.RPL_INIT_SLAVE_FUNC MISMATCHES IN DAILY-5.5 Problem: sys_vars.rpl_init_slave_func test was not recorded after the last edit. It was disabled on 5.1 after seeing failures due to the above reason. No old failures as this suite never ran with pb2 on 5.1 Fix: Added assert condition after wait for checks. Recorded test and enabled it.	13 years ago
Venkatesh Duggirala	e8a0b9f943	Bug#16765278 DELETE SQL_LOAD_MB* FILE (TEMP FILE) CREATED BY BINLOG_KILLED_SIMULATE.TEST 'mysqbinlog' tool creates a temporary file while preparing LOAD DATA QUERY. These files needs to be deleted at the end of the test script otherwise these files are left out in the daily-run machines, causing "no space on device issues" Fix: Delete them at the end of these test scripts 1) execute mysqlbinlog with --local-load option to create these files in a specified tmpdir 2) delete the tmpdir at the end of the test script	13 years ago
Sujatha Sivakumar	0e763f4db5	Bug#11829838: ALTER TABLE NOT BINLOGGED WITH --BINLOG-IGNORE-DB AND FULLY QUALIFIED TABLE Problem: ======= An ALTER TABLE statement is not written to binlog if server started with "--binlog-ignore-db some database" and 'fully qualified' table names are used in the ALTER TABLE statement altering table different from current database context. Analysis: ======== The above mentioned problem not only affects "ALTER TABLE" statements but also to all kind of statements. Once the current default database becomes "NULL" none of the statements will be binlogged. The current behaviour is such that if the user has specified restrictions on which database needs to be replicated and the default db is not specified, then do not replicate. This means that "NULL" is considered to be equivalent to everything (default db = null implied ignore don't log the statement). Fix: === "NULL" should not be considered as equivalent to everything. Since the filtering criteria is not equal to "NULL" the statement should be logged into binlog. mysql-test/suite/rpl/r/rpl_loaddata_m.result: Earlier when defalut database was "NULL" DROP TABLE was not getting logged. Post this fix it will be logged and the DROP will fail at slave as the table creation was skipped by master as --binlog-ignore-db=test. mysql-test/suite/rpl/t/rpl_loaddata_m.test: Earlier when defalut database was "NULL" DROP TABLE was not getting logged. Post this fix it will be logged and the DROP will fail at slave as the table creation was skipped by master as --binlog-ignore-db=test. sql/rpl_filter.cc: Replaced DBUG_RETURN(0) with DBUG_RETURN(1).	13 years ago
Nirbhay Choubey	7a4c361552	Bug#12671635 : Updating embedded tests.	13 years ago
Nirbhay Choubey	9be9f11f90	Bug#12671635 : Fixing test cases.	13 years ago
Satya Bodapati	57674d6342	Testcase fix for Bug#14147491 Sleep 1sec before remove_file to solve windows pb2 issues. We hope that after sleep, the access to the file will not be denied.	13 years ago
Satya Bodapati	8b129a8b41	Testcase fix for Bug#14147491 move_file fails randomly on windows if the destination file exists. Using remove_file before move_file mtr test command.	13 years ago
Satya Bodapati	6ca27ddec0	Testcase fix for BUG#14147491 The random failure will be fixed by Bug#16263506 and this patch Approved by Marko. rb#1988	13 years ago
Shivji Kumar Jha	85c299dd98	BUG#15965353- RPL.RPL_ROW_UNTIL FAILS ON PB2, PLATFORM= MACOSX10.6 X86_64 MAX post push fix	13 years ago
Shivji Kumar Jha	5fcf40a2aa	BUG#15965353- RPL.RPL_ROW_UNTIL FAILS ON PB2, PLATFORM= MACOSX10.6 X86_64 MAX Problem: The test was failing on pb2's mac machine because it was not cleaned up properly. The test checks if the command 'start slave until' throws a proper error when issued with a wrong number/type of parameters. After this,the replication stream was stopped using the include file 'rpl_end.inc'. The errors thrown earlier left the slave in an inconsistent state to be closed by the include file which was caught by the mac machine. Fix: Started slave by invoking start_slave.inc to have a working slave before calling rpl_reset.inc Problem: The test file was not in a good shape. It tested start slave until relay log file/pos combination wrongly. A couple of commands were executed at master and replicated at slave. Next, the coordinates in terms of relay log file and pos were noted down followed by reset slave and start slave until saved relay log file/pos. Reset slave deletes all relay log files and makes the slave forget its replication position. So, using the saved coordiantes after reset slave is wrong. Fix: Split the test in two parts: a) Test for start slave until master log file/pos and checking for correct errors in the failure scenarios. b) Test for start slave until relay log file/pos. Problem: The variables auto_increment_increment and auto_increment_offset were set in the the include file rpl_init.inc. This was only configured for some connections that are rarely used by test cases, so likely that it will cause confusion. If replication tests want to setup these variables they should do so explicitly. Fix: a) Removed code to set the variables auto_increment_increment and auto_increment_offset in the include file. b) Updated tests files using the same.	13 years ago
Shivji Kumar Jha	eb3814b0b3	BUG#12359942- REPLICATION TEST FROM ENGINE SUITE RPL_ROW_UNTIL TIMES OUT post push fix: rpl_stm_until.test was disabled because of this bug. Enabled and fixed it. Removed a part of the test that was obsolete. It tested replication from 4.0 master to 5.0 slave.	13 years ago
Mattias Jonsson	e96182824d	Bug#16274455: CAN NOT ACESS PARTITIONED TABLES WHEN DOWNGRADED FROM 5.6.11 TO 5.6.10 Problem was new syntax not accepted by previous version. Fixed by adding version comment of /!50531 around the new syntax. Like this in the .frm file: 'PARTITION BY KEY /!50611 ALGORITHM = 2 / () PARTITIONS 3' and also changing the output from SHOW CREATE TABLE to: CREATE TABLE t1 (a INT) /!50100 PARTITION BY KEY / /!50611 ALGORITHM = 1 / /!50100 () PARTITIONS 3 / It will always add the ALGORITHM into the .frm for KEY [sub]partitioned tables, but for SHOW CREATE TABLE it will only add it in case it is the non default ALGORITHM = 1. Also notice that for 5.5, it will say /!50531 instead of /*!50611, which will make upgrade from 5.5 > 5.5.31 to 5.6 < 5.6.11 fail! If one downgrades an fixed version to the same major version (5.5 or 5.6) the bug 14521864 will be visible again, but unless the .frm is updated, it will work again when upgrading again. Also fixed so that the .frm does not get updated version if a single partition check passes.	13 years ago
Venkatesh Duggirala	06400b63e7	Bug#16247322- MTR NOT RUNNING SYS_VARS TEST SUITE FOR 5.1 SYS_VARS suite is not enabled in MTR by default run. Enabling it with this check-in. mysql-test/suite/sys_vars/t/disabled.def: Till the bugs are fixed, disabling the failed test scripts	13 years ago
Mattias Jonsson	2df2e2617c	post-push test result update for bug#14521864.	13 years ago
Yasufumi Kinoshita	c3d2803c43	Bug #16220051 : INNODB_BUG12400341 FAILS ON VALGRIND WITH TOO MANY ACTIVE CONCURRENT TRANSACTION innodb_bug12400341.test is disabled for valgrind daily test. It might be affected by the previous test's undo slots existing, because of slower execution.	13 years ago
Venkatesh Duggirala	7e0901b97f	Bug#16084594 USER_VAR ITEM IN 'LOAD FILE QUERY' WAS NOT PROPERLY QUOTED IN BINLOG FILE Problem: In load data file query, User variables are allowed inside "Into_list" and "Set_list". These user variables used inside these two lists are not properly guarded with backticks while server is writting into binlog. Hence user variable names like a` cannot be used in this context. Fix: Properly quote these variables while writting into binlog mysql-test/r/func_compress.result: changing result file mysql-test/r/variables.result: changing result file mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: changing result file sql/item_func.cc: Quote the user variable items	13 years ago
Marko Mäkelä	e7283ceaf0	Bug#16067973 DROP TABLE SLOW WHEN IT DECOMPRESS COMPRESSED-ONLY PAGES buf_page_get_gen(): Do not attempt to decompress a compressed-only page when mode == BUF_PEEK_IF_IN_POOL. This mode is only being used by btr_search_drop_page_hash_when_freed(). There cannot be any adaptive hash index pointing to a page that does not exist in uncompressed format in the buffer pool. innodb_buffer_pool_evict_update(): New function for debug builds, to handle SET GLOBAL innodb_buffer_pool_evicted='uncompressed' by evicting all uncompressed page frames of compressed tablespaces from the buffer pool. rb#1873 approved by Jimmy Yang	13 years ago
Astha Pareek	c8de0f9aec	BUG#11761680 disabled binlog_spurious_ddl_errors on mysql-5.5	13 years ago
Astha Pareek	9b904d35af	Description The test, binlog.binlog_spurious_ddl_errors was failing on pb2 at the statement "UNINSTALL PLUGIN example;" with this warning: "Warning 1620 Plugin is busy and will be uninstalled on shutdown " Fix Spurious warnings occur in the test since we do not empty the Query cache, used by the example plugin at the time of creating tables using the plugin. Hence, the query chache is flushed before uninstalling the plugin. Also, as part of running the test across platforms, the plugin installation script is changed.	13 years ago
Olav Sandstaa	e7ad5e36d4	Fix for Bug#14636211 WRONG RESULT (EXTRA ROW) ON A FROM SUBQUERY WITH A VARIABLE AND ORDER BY Bug#16035412 MYSQL SERVER 5.5.29 WRONG SORTING USING COMPLEX INDEX This is a fix for a regression introduced by Bug#12667154: Bug#12667154 attempted to fix a performance problem with subqueries that did filesort. For doing filesort, the optimizer creates a quick select object to use when building the sort index. This quick select object was deleted after the first call to create_sort_index(). Thus, for queries where the subquery was executed multiple times, the quick object was only used for the first execution. For all later executions of the subquery, filesort used a complete table scan for building the sort index. The fix for Bug#12667154 tried to fix this by not deleting the quick object after the first execution of create_sort_index() so that it would be re-used for building the sort index by the following executions of the subquery. This regression introduced in Bug#12667154 is that due to not deleting the quick select object after building the sort index, the quick object could in some cases be used also during the second phase of the execution of the subquery instead of using the created sort index. This caused wrong results to be returned. The fix for this issue is to delete the reference to the select object after it has been used in create_sort_index(). In this way the select and quick objects will not be available when doing the second phase of the execution of the select operation. To ensure that the select object can be re-used for the following executions of the subquery we make a copy of the select pointer. This is used for restoring the select object after the select operation is completed. mysql-test/suite/innodb/r/innodb_mysql.result: Changed explain output: The explain now contains "Using where" since we have restored the select pointer after doing the filesort operation. sql/sql_select.cc: Change create_sort_index() so that it always sets the pointer to the select object to NULL. This is done in order to avoid that the select->quick object can be used when execution the main part of the select operation. sql/sql_select.h: New member in JOIN_TAB: saved_select. Used by create_sort_index to make a backup copy of the select pointer.	13 years ago
Olav Sandstaa	fd5380b496	Fix for Bug#14636211 WRONG RESULT (EXTRA ROW) ON A FROM SUBQUERY WITH A VARIABLE AND ORDER BY Bug#16035412 MYSQL SERVER 5.5.29 WRONG SORTING USING COMPLEX INDEX This is a fix for a regression introduced by Bug#12667154: Bug#12667154 attempted to fix a performance problem with subqueries that did filesort. For doing filesort, the optimizer creates a quick select object to use when building the sort index. This quick select object was deleted after the first call to create_sort_index(). Thus, for queries where the subquery was executed multiple times, the quick object was only used for the first execution. For all later executions of the subquery, filesort used a complete table scan for building the sort index. The fix for Bug#12667154 tried to fix this by not deleting the quick object after the first execution of create_sort_index() so that it would be re-used for building the sort index by the following executions of the subquery. This regression introduced in Bug#12667154 is that due to not deleting the quick select object after building the sort index, the quick object could in some cases be used also during the second phase of the execution of the subquery instead of using the created sort index. This caused wrong results to be returned. The fix for this issue is to delete the reference to the select object after it has been used in create_sort_index(). In this way the select and quick objects will not be available when doing the second phase of the execution of the select operation. To ensure that the select object can be re-used for the following executions of the subquery we make a copy of the select pointer. This is used for restoring the select object after the select operation is completed. mysql-test/suite/innodb/r/innodb_mysql.result: Changed explain output: The explain now contains "Using where" since we have restored the select pointer after doing the filesort operation. sql/sql_select.cc: Change create_sort_index() so that it always sets the pointer to the select object to NULL. This is done in order to avoid that the select->quick object can be used when execution the main part of the select operation. sql/sql_select.h: New member in JOIN_TAB: saved_select. Used by create_sort_index to make a backup copy of the select pointer.	13 years ago
Marc Alff	cc2df0069d	Bug#16060864 SEGMENTATION FAULT IN PERFORMANCE_SCHEMA WITH HISTORY SIZE 0 Before this fix, configuring the server with: - performance_schema_events_waits_history_size=0 - performance_schema_events_waits_history_long_size=0 could cause a crash in the performance schema. These settings to 0 are intended to be valid and supported, and are in fact working properly in mysql 5.6 and up already. This fix backports the code fix and test cases from mysql 5.6 to the mysql 5.5 release.	13 years ago
Annamalai Gurusami	76059a4a1d	Fixing a pb2 issue. There is some difference in the output in my local machine and pb2 machines in the explain output.	13 years ago
Annamalai Gurusami	d426504b9e	Bug #14200010 NEWLY CREATED TABLE DOESN'T ALLOW FOR LOOSE INDEX SCANS Problem: Before the ALTER TABLE statement, the array dict_index_t::stat_n_diff_key_vals had proper values calculated and updated. But after the ALTER TABLE statement, all the values of this array is 0. Because of this statistics returned by innodb_rec_per_key() is different before and after the ALTER TABLE statement. Running the ANALYZE TABLE command populates the statistics correctly. Solution: After ALTER TABLE statement, set the flag dict_table_t::stat_initialized correctly so that the table statistics will be recalculated properly when the table is next loaded. But note that we still don't choose the loose index scans. This fix only ensures that an ALTER TABLE does not change the optimizer plan. rb://1639 approved by Marko and Jimmy.	13 years ago
Shivji Kumar Jha	51d43baa66	BUG#12359942 - REPLICATION TEST FROM ENGINE SUITE RPL_ROW_UNTIL TIMES OUT patch to fix post push falures in pb2 mysql-test/suite/rpl/r/rpl_row_until.result: changes to account for the changes made in corresponding test file. mysql-test/suite/rpl/t/disabled.def: disabled test in macosx mysql-test/suite/rpl/t/rpl_row_until.test: replaced static relayy log file by an mtr variable which saves the name of relay log file.	13 years ago
Pedro Gomes	86718b969c	Bug#13545447 RPL_ROTATE_LOGS FAILS DUE TO CONCURRENCY ISSUES IN REP. CODE RPL_ROTATE_LOGS has been failing sporadically in what seems a problem related to routines that update the coordinates. However, the test lacks proper assert statments and because of this the debug information upon failure simply points to the content mismatch between the test and the result file. Not as a solution, but as a improvement to the test to better debug this failure, new assert statments were added to the test. @rpl_rotate_logs.test Added new assert statments reducing the dependency on the result file. @rpl_rotate_logs.result Added new content to the result file to match the test changes	13 years ago
Manish Kumar	14b18b2785	BUG#13812374 - RPL.RPL_REPORT_PORT FAILS OCCASIONALLY ON PB2 Problem: The problem with the test is that the slave returns from start_slave.inc call too early before the list is actually actualised. This caused the slave stale data to be reported. Fix: Added a wait in the test till the slave's IO status is changed to "Waiting for master to send event" which which ensures the list is correctly updated.	13 years ago
Shivji Kumar Jha	07ffa9c767	BUG#12359942 - REPLICATION TEST FROM ENGINE SUITE RPL_ROW_UNTIL TIMES OUT === Problem === The test is dependent on binlog positions and checks to see if the command 'START SLAVE' functions correctly with the 'UNTIL' clause added to it. The 'UNTIL' clause is added to specify that the slave should start and run until the SQL thread reaches a given point in the master binary log or in the slave relay log. The test uses hard coded values for MASTER_LOG_POS and RELAY_LOG_POS, instead of extracting it using query_get_value() function. There is a test 'rpl.rpl_row_until' which does the similar thing but uses query_get_value() function to set the values of MASTER_LOG_POS/ RELAY_LOG_POS. To be precise, rpl.rpl_row_until is a modified version of engines/func.rpl_row_until.test. The use of hard coded values may lead the slave to stop at a position which may differ from the expected position in the binlog file, an example being the failure of engines/funcs.rpl_row_until in mysql-5.1 given as: "query 'select * from t2' failed. Table 'test.t2' doesn't exist". In this case, the slave actually ran a couple of extra commands as a result of which the slave first deleted the table and then ran a select query on table, leading to the above mentioned failure. === Fix === 1) Fixed the code for failure seen in rpl.rpl_row_until. This test was also failing although the symptoms of failure were different. 2) Copied the contents from rpl.rpl_row_until into into engines/funcs.rpl.rpl_row_until. 3) Updated engines/funcs.rpl_row_until.result accordingly. mysql-test/suite/engines/funcs/r/rpl_row_until.result: modified to accomodate the changes in corresponding test file. mysql-test/suite/engines/funcs/t/disabled.def: removed from the list of disabled tests. mysql-test/suite/engines/funcs/t/rpl_row_until.test: fixed rpl.rpl_row_until and copied its content to engines/funcs.rpl_row_until. The reason being both are same tests but rpl.rpl_row_until is an updated version. mysql-test/suite/rpl/t/disabled.def: removed from the list of disabled tests. sql/sql_repl.cc: Added a check to catch an improper combination of arguements passed to 'START SLAVE UNTIL'. Earlier, START SLAVE UNTIL MASTER_LOG_FILE='master-bin.000001', MASTER_LOG_POS=561, RELAY_LOG_POS=12; passed. It is now detected and an error is reported.	13 years ago
Nuno Carvalho	fb313032a6	BUG#15891524: RLI_FAKE MODE IS NOT UNSET AFTER BINLOG REPLAY When a binlog is replayed into a server, e.g.: $ mysqlbinlog binlog.000001 \| mysql it sets a pseudo slave mode on the client connection in order to server be able to read binlog events, there is, a format description event is needed to correctly read following events. Also this pseudo slave mode applies to the current connection replication rules that are needed to correctly apply binlog events. If a binlog dump is sourced on a connection, this pseudo slave mode will remains after it, what will apply unexpected rules from customer perspective to following commands. Added a new SET statement to binlog dump that will unset pseudo slave mode at the end of dump file.	13 years ago
Satya Bodapati	64dcbd6a49	Bug#14147491 - INFINITE LOOP WHEN OPENING A CORRUPTED TABLE This bug is fixed by Bug#14251529. Only testcase from the contribution is used.	13 years ago
unknown	bd5c93304d	remove usage of --skip-ndb from collections - no need to use --skip-ndb in collections files anymore, since long but more clear logic after recent mtr.pl fixes. ndb tests are never run in MySQL Server unless explicitly requested - remove sys_vars.ndb_log_update_as_write_basic.test and sys_vars.ndb_log_updated_only_basic.result since MySQL Server does not have those options. - Only sys_vars.have_ndbcluster_basic left since MySQL Server has that variable hardcoded.	13 years ago
Jimmy Yang	e42cd2db91	Fix Bug #14753402 - FAILING ASSERTION: LEN == IFIELD->FIXED_LEN rb://1411 approved by Marko	13 years ago
Yasufumi Kinoshita	5a7553f36a	Bug #14676111 WRONG PAGE_LEVEL WRITTEN FOR UPPER THAN FATHER PAGE AT BTR_LIFT_PAGE_UP() btr_lift_page_up() writes wrong page number (different by -1) for upper than father page. But in almost all of the cases, the father page should be root page, no upper pages. It is very rare path. In addition the leaf page should not be lifted unless the father page is root. Because the branch pages should not become the leaf pages. rb://1336 approved by Marko Makela.	13 years ago
Vasil Dimov	04195c30c1	This is a backport of "WL#5674 InnoDB: report all deadlocks (Bug#1784)" from MySQL 5.6 into MySQL 5.5 Will close Bug#14515889 BACKPORT OF INNODB DEADLOCK LOGGING TO 5.5 The original implementation is in vasil.dimov@oracle.com-20101213120811-k2ldtnao2t6zrxfn Approved by: Jimmy (rb:1535)	13 years ago
Aditya A	078d7a87c9	Bug#11751825 - OPTIMIZE PARTITION RECREATES FULL TABLE INSTEAD JUST PARTITION Follow up patch to address the pb2 failures.	13 years ago
Shivji Kumar Jha	7c7de142a3	BUG#14659685 - main.mysqlbinlog_row_myisam and main.mysqlbinlog_row_innodb are skipped by mtr === Problem === The following tests are wrongly placed in main suite and as a result these are not run with proper binlog format combinations. Some are always skipped by mtr. 1) mysqlbinlog_row_myisam 2) mysqlbinlog_row_innodb 3) mysqlbinlog_row.test 4) mysqlbinlog_row_trans.test 5) mysqlbinlog-cp932 6) mysqlbinlog2 7) mysqlbinlog_base64 === Background === mtr runs the tests placed in main suite with binlog format=stmt. Those that need to be tested against binlog format=row or mixed or more than one binlog format and require only one mysql server are placed in binlog suite. mtr runs tests in binlog suite with all three binlog formats(stmt,row and mixed). === Fix === 1) Moved the test listed in problem section above to binlog suite. 2) Added prefix "binlog_" to the name of each test case moved. Renamed the coresponding result files and option files accordingly. mysql-test/extra/binlog_tests/mysqlbinlog_row_engine.inc: include file for mysqlbinlog_row_myisam.test and mysqlbinlog_row_myisam.test which are being moved to binlog suite. mysql-test/suite/binlog/r/binlog_mysqlbinlog-cp932.result: result file for mysqlbinlog-cp932.test which is being moved to binlog suite. mysql-test/suite/binlog/r/binlog_mysqlbinlog2.result: result file for mysqlbinlog2.test which is being moved to binlog suite. mysql-test/suite/binlog/r/binlog_mysqlbinlog_base64.result: result file for mysqlbinlog_base64.test which is being moved to binlog suite. mysql-test/suite/binlog/r/binlog_mysqlbinlog_row.result: result file for mysqlbinlog_row.test which is being moved to binlog suite. mysql-test/suite/binlog/r/binlog_mysqlbinlog_row_innodb.result: result file for mysqlbinlog_row_innodb.test which is being moved to binlog suite. mysql-test/suite/binlog/r/binlog_mysqlbinlog_row_myisam.result: result file for mysqlbinlog_row_myisam.test which is being moved to binlog suite. mysql-test/suite/binlog/r/binlog_mysqlbinlog_row_trans.result: result file for mysqlbinlog_row_trans.test which is being moved to binlog suite. mysql-test/suite/binlog/t/binlog_mysqlbinlog-cp932-master.opt: option file for mysqlbinlog-cp932.test which is being moved to binlog suite. mysql-test/suite/binlog/t/binlog_mysqlbinlog-cp932.test: the test requires binlog format=stmt or mixed. Since, it was placed in main suite earlier, it was only run with binlog format=stmt, and hence this test was never run with binlog format=mixed. mysql-test/suite/binlog/t/binlog_mysqlbinlog2.test: the test requires binlog format=stmt or mixed. Since, it was placed in main suite earlier, it was only run with binlog format=stmt, and hence this test was never run with binlog format=mixed. mysql-test/suite/binlog/t/binlog_mysqlbinlog_base64.test: the test requires binlog format=row. Since, it was placed in main suite earlier, it was only run with binlog format=stmt, and hence this test was always skipped by mtr. mysql-test/suite/binlog/t/binlog_mysqlbinlog_row.test: the test requires binlog format=row. Since, it was placed in main suite earlier, it was only run with binlog format=stmt, and hence this test was always skipped by mtr. mysql-test/suite/binlog/t/binlog_mysqlbinlog_row_innodb.test: the test requires binlog format=row. Since, it was placed in main suite earlier, it was only run with binlog format=stmt, and hence this test was always skipped by mtr. mysql-test/suite/binlog/t/binlog_mysqlbinlog_row_myisam.test: the test requires binlog format=row. Since, it was placed in main suite earlier, it was only run with binlog format=stmt, and hence this test was always skipped by mtr. mysql-test/suite/binlog/t/binlog_mysqlbinlog_row_trans.test: the test requires binlog format=row. Since, it was placed in main suite earlier, it was only run with binlog format=stmt, and hence this test was always skipped by mtr.	13 years ago
Krunal Bauskar krunal.bauskar@oracle.com	500d2ebe6f	removing .... will re-add using merge. for some reason initial mysql-5.1 version is not connected to mysql-5.5	13 years ago
Krunal Bauskar krunal.bauskar@oracle.com	779960205f	bug#14765606: ensure select is active before killing it else kill signal is ignored	13 years ago
Krunal Bauskar krunal.bauskar@oracle.com	04c7730006	removed warning message as they have changed in mysql-5.6 and mysql-trunk and this is left over from changes that got up-merged	13 years ago
Krunal Bauskar krunal.bauskar@oracle.com	ed6732dd16	bug#14704286	13 years ago
Krunal Bauskar krunal.bauskar@oracle.com	9bfc910f2f	bug#14704286	13 years ago
Annamalai Gurusami	378a7d1ef5	Bug #14036214 MYSQLD CRASHES WHEN EXECUTING UPDATE IN TRX WITH CONSISTENT SNAPSHOT OPTION A transaction is started with a consistent snapshot. After the transaction is started new indexes are added to the table. Now when we issue an update statement, the optimizer chooses an index. When the index scan is being initialized via ha_innobase::change_active_index(), InnoDB reports the error code HA_ERR_TABLE_DEF_CHANGED, with message stating that "insufficient history for index". This error message is propagated up to the SQL layer. But the my_error() api is never called. The statement level diagnostics area is not updated with the correct error status (it remains in Diagnostics_area::DA_EMPTY). Hence the following check in the Protocol::end_statement() fails. 516 case Diagnostics_area::DA_EMPTY: 517 default: 518 DBUG_ASSERT(0); 519 error= send_ok(thd->server_status, 0, 0, 0, NULL); 520 break; The fix is to backport the fix of bugs 14365043, 11761652 and 11746399. 14365043 PROTOCOL::END_STATEMENT(): ASSERTION `0' FAILED 11761652 HA_RND_INIT() RESULT CODE NOT CHECKED 11746399 RETURN VALUES OF HA_INDEX_INIT() AND INDEX_INIT() IGNORED rb://1227 approved by guilhem and mattiasj.	13 years ago
Rohit Kalhans	5530c5e38d	BUG#14548159: NUMEROUS CASES OF INCORRECT IDENTIFIER QUOTING IN REPLICATION Problem: Misquoting or unquoted identifiers may lead to incorrect statements to be logged to the binary log. Fix: we use specialized functions to append quoted identifiers in the statements generated by the server.	13 years ago

1 2 3 4 5 ...

3080 Commits (1c0122c5c121010cc2250e27af88b9e8d58bc761)