summaryrefslogtreecommitdiff
path: root/mysql-test/suite
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-17507 Make MTR tests work for builds without Aria for temporary tablesbb-10.2-mdev17507Elena Stepanova2018-11-183-0/+4
| | | | Skip tests which expectedly fail when Aria is not used for temporary tables
* Merge branch '10.1' into 10.2Oleksandr Byelkin2018-11-152-0/+117
|\
| * Merge branch '10.0' into 10.1Oleksandr Byelkin2018-11-152-0/+117
| |\
| | * Merge branch '5.5' into 10.0Oleksandr Byelkin2018-11-152-0/+117
| | |\
| | | * MDEV-17724 Wrong result for BETWEEN 0 AND 18446744073709551615Alexander Barkov2018-11-152-0/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The fix for "MDEV-17698 MEMORY engine performance regression" previously fixed this problem. - Adding the test for MDEV-17724 - Re-recording wrong results for tests: * engines/iuds/r/insert_number * engines/iuds/r/update_delete_number which started to fail since MDEV-17698
* | | | MDEV-17645 innodb.log_file_name_debug does not clean up after itselfMarko Mäkelä2018-11-082-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The test innodb.log_file_name_debug failed to ensure that the bogus redo log record that its debug injection emitted would be consumed by a redo log checkpoint before running a subsequent test, which could perform crash recovery. Add an extra shutdown to ensure that a redo log checkpoint is generated. In this way, the following will succeed: ./mtr --no-reorder innodb.log_file_name_debug innodb.read_only_recovery
* | | | MDEV-14528 followup.Andrei Elkin2018-11-071-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was a failure in rpl_delayed_slave after recent MDEV-14528 commit. The parallel applier should not set its Relay_log::last_master_timestamp from Format-descriptor log event. The latter may reflect a deep past so Seconds-behind-master will be computed through it and displayed all time while the first possibly "slow" group of events is executed. The main MDEV-14528 is refined, rpl_delayed_slave now passes also in the parallel mode.
* | | | MDEV-14528: Disable a failing testMarko Mäkelä2018-11-071-0/+1
| | | |
* | | | Merge 10.1 into 10.2Marko Mäkelä2018-11-072-0/+61
|\ \ \ \ | |/ / /
| * | | MDEV-17230: encryption_key_id from alter is ignored by encryption threadsJan Lindström2018-11-062-0/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Background: Used encryption key_id is stored to encryption metadata i.e. crypt_data that is stored on page 0 of the tablespace of the table. crypt_data is created only if implicit encryption/not encryption is requested i.e. ENCRYPTED=[YES|NO] table option is used fil_create_new_single_table_tablespace on fil0fil.cc. Later if encryption is enabled all tables that use default encryption mode (i.e. no encryption table option is set) are encrypted with default encryption key_id that is 1. See fil_crypt_start_encrypting_space on fil0crypt.cc. ha_innobase::check_table_options() If default encryption is used and encryption is disabled, you may not use nondefault encryption_key_id as it is not stored anywhere.
* | | | MDEV-14528 Track master timestamp in case rolling back to serial replicationIgor Mazur2018-11-062-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When replicated events are from Master unaware of MariaDB GTID their handling by the Parallel slave misses Seconds_Behind_Master updating. In the bug condition the Show-Slave-Status' field remains unchanged. Because in such case event execution is sequential the bug is fixed with deploying the same logics as in the explicit single-threaded mode with is to set Relay_log_event::last_master_timestamp member early at the end of event reading from the relay log.
* | | | Merge 10.1 into 10.2Marko Mäkelä2018-11-0646-64/+1036
|\ \ \ \ | |/ / /
| * | | Merge 10.0 into 10.1Marko Mäkelä2018-11-052-10/+229
| |\ \ \ | | |/ /
| | * | MDEV-13671 InnoDB should use case-insensitive column name comparisons like ↵Eugene Kosov2018-11-052-10/+229
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the rest of the server Problem affects INPLACE ALTER rename columns. innobase_rename_column_try(): some strcmp() was replaced with my_strcasecmp(), queries to update data dictionary was updated to not match column name case.
| * | | MDEV-15890 Strange error message if you try to FLUSH TABLES <view> after ↵Alexey Botchkov2018-11-034-20/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | LOCK TABLES <view>. LOCK view WRITE shouldn't block FLUSH view. So we set the view's mdl_request type to it's tables.
| * | | update rdiffs for 32bitSergei Golubchik2018-10-312-49/+57
| | | |
| * | | Fix innodb.table_flags,debugMarko Mäkelä2018-10-316-13/+273
| | | |
| * | | disabling a crashing testSergei Golubchik2018-10-311-1/+1
| | | |
| * | | Merge branch '10.0' into 10.1Sergei Golubchik2018-10-316-0/+388
| |\ \ \ | | |/ /
| | * | MDEV-12023 Assertion failure sym_node->table != NULL on startupMarko Mäkelä2018-10-306-0/+388
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | row_drop_table_for_mysql(): Avoid accessing non-existing dictionary tables. dict_create_or_check_foreign_constraint_tables(): Add debug instrumentation for creating and dropping a table before the creation of any non-core dictionary tables. trx_purge_add_update_undo_to_history(): Adjust a debug assertion, so that it will not fail due to the test instrumentation.
| * | | Merge branch '10.0' into 10.1Sergei Golubchik2018-10-3032-7/+637
| |\ \ \ | | |/ /
| | * | MDEV-15919 lower_case_table_names does not behave as expectedSergei Golubchik2018-10-292-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | followup for e31e697f17f Fix the test not to fail on Mac OS X (lower_case_table_names=0 prevents mysqld from starting on case insensitive filesystem)
| | * | Merge branch '5.5' into 10.0Sergei Golubchik2018-10-2717-0/+421
| | |\ \ | | | |/
| | | * Bug#27799513: POTENTIAL DOUBLE FREE OR CORRUPTION OF HEAP INFO (HP_INFO)Sergei Golubchik2018-10-232-0/+13
| | | | | | | | | | | | | | | | test case
| | | * Merge branch 'mysql/5.5' into 5.5Sergei Golubchik2018-10-231-6/+6
| | | |\
| | | | * Bug#27788907 SOME FILE OPERATIONS IN MF_IOCACHE2.C ARE NOT INSTRUMENTEDmysql-5.5.62Marc Alff2018-08-201-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MySQL bug number 90264 Contribution by Yura Sorokin. Problem: File mysys/mf_iocache2.c contains non instrumented file io operations. This causes inaccurate statistics in PERFORMANCE_SCHEMA. Solution: Use the instrumentation apis (mysql_file_tell instead of my_tell, etc).
| | | * | MDEV-15919 lower_case_table_names does not behave as expected(nor...Sachin2018-10-1713-0/+245
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | consistently) on Replication Slave lower_case_table_names 0 -> 1 replication works, it's safe as long as mixed case names mapping to the lower case ones is one-to-one
| | | * | MDEV-9137 MariaDB Crash on Query Using Aria EngineSergei Golubchik2018-09-222-0/+91
| | | | | | | | | | | | | | | | | | | | more tests
| | | * | MDEV-9137 MariaDB Crash on Query Using Aria EngineSergei Golubchik2018-09-222-0/+5
| | | | | | | | | | | | | | | | | | | | fix for 2-level ft indexes and boolean search in Aria
| | | * | MDEV-9137 MariaDB Crash on Query Using Aria EngineSergei Golubchik2018-09-222-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | update the code to match semantics of `key` - it's not a (char*) pointer to the buffer as in MyISAM.
| | | * | MDEV-9137 MariaDB Crash on Query Using Aria EngineSergei Golubchik2018-09-222-0/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two bugs in Aria, related to 2-level fulltext indexes: * REPAIR calculated the key number incorrectly * CHECK copied the key into last_key too early and checking the second-level btree was overwriting it
| | * | | MDEV-17533 Merge new release of InnoDB 5.6.42 to 10.0Marko Mäkelä2018-10-252-1/+38
| | | | | | | | | | | | | | | | | | | | Also, add a test for a bug that does not seem to affect MariaDB.
| | * | | MDEV-17532 Performance_schema reports wrong directory for the temporary ↵Marko Mäkelä2018-10-253-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | files of ALTER TABLE…ALGORITHM=INPLACE row_merge_file_create_low(): Pass the directory of the temporary file to the PSI_FILE_CALL.
| | * | | MDEV-17531 Crash in RENAME TABLE with FOREIGN KEY and FULLTEXT INDEXMarko Mäkelä2018-10-252-0/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In RENAME TABLE, when an error occurs while renaming FOREIGN KEY constraint, that error would be overwritten when renaming the InnoDB internal tables related to FULLTEXT INDEX. row_rename_table_for_mysql(): Do not attempt to rename the internal tables if an error already occurred. This problem was originally reported as Oracle Bug#27545888.
| | * | | MDEV-12547: InnoDB FULLTEXT index has too strict ↵Thirunarayanan Balathandayuthapani2018-10-164-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | innodb_ft_result_cache_limit max limit - Backported the MYSQL_SYSVAR_SIZE_T to 10.0 - The parameter innodb_ft_result_cache_limit was only 32 bits wide also on 64-bit systems. Make it size_t, so that it will be 64 bits on 64-bit systems. - Added a test case that show how innodb_ft_result_cache_limit variables behaves in 32bit and 64 bit system.
| | * | | fix test suite after MDEV-15438Vladislav Vaintroub2018-10-122-0/+2
| | | | |
| * | | | MDEV-14431 binlog.binlog_flush_binlogs_delete_domain failed in buildbotAndrei Elkin2018-10-162-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The test and also rpl_gtid_delete_domain failed on PPC64 platform due to an incorrectly specified actual key for searching in a gtid domain system hash. While the correct size is 32 bits the supplied value was 8 bytes of long int size on the platform. The problem became evident thanks to the big endiness which cut off the *least* significant part of the value field. Fixed with correcting a dynamic array initialization to hold now uint32 values as well as the values extraction for searching in the gtid domain system hash. A new added test ensures no overflowed values are accepted for deletion which prevents inadvertent action. Notice though MariaDB [test]> set @@session.gtid_domain_id=(1 << 32) + 1; MariaDB [test]> show warnings; +---------+------+--------------------------------------------------------+ | Level | Code | Message | +---------+------+--------------------------------------------------------+ | Warning | 1292 | Truncated incorrect gtid_domain_id value: '4294967297' | +---------+------+--------------------------------------------------------+ MariaDB [test]> select @@session.gtid_domain_id; +--------------------------+ | @@session.gtid_domain_id | +--------------------------+ | 4294967295 | +--------------------------+
| * | | | Merge branch 'gtid_table_garbage_rows' into 10.1Kristian Nielsen2018-10-132-0/+23
| |\ \ \ \
| | * | | | Fix accumulation of old rows in mysql.gtid_slave_posKristian Nielsen2018-10-072-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This would happen especially in optimistic parallel replication, where there is a good chance that a transaction will be rolled back (due to conflicts) after it has executed record_gtid(). If the transaction did any deletions of old rows as part of record_gtid(), those deletions will be undone as well. And the code did not properly ensure that the deletions would be re-tried. This patch makes record_gtid() remember the list of deletions done as part of a transaction. Then in rpl_slave_state::update() when the changes have been committed, we discard the list. However, in case of error and rollback, in cleanup_context() we will instead put the list back into rpl_global_gtid_slave_state so that the deletions will be re-tried later. Probably fixes part of the cause of MDEV-12147 as well. Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
* | | | | | MDEV-17349 Assertion `!table || (!table->read_set || ↵Sergei Golubchik2018-11-042-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bitmap_is_set(table->read_set, field_index))' failed on concurrent SELECT and DELETE after RENAME from table with index on virtual column Race condition. field->flags were copied from s->field->flags during field->clone(), early in open_table_from_share(). But s->field->flags were getting their PART_INDIRECT_KEY_FLAG bit much later in TABLE::mark_columns_used_by_virtual_fields() and only once per share. If two threads were executing the code between field->clone() and mark_columns_used_by_virtual_fields() at the same time, only one would get PART_INDIRECT_KEY_FLAG bits in field[].
* | | | | | MDEV-17073 INSERT…ON DUPLICATE KEY UPDATE became more deadlock-proneMarko Mäkelä2018-11-025-45/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | thd_rpl_stmt_based(): A new predicate to check if statement-based replication is active. (This can also hold when replication is not in use, but binlog is.) que_thr_stop(), row_ins_duplicate_error_in_clust(), row_ins_sec_index_entry_low(), row_ins(): On a duplicate key error, only lock all index records when statement-based replication is in use.
* | | | | | MDEV-16774 SET PASSWORD and ALTER USER with slightly different resultsSergei Golubchik2018-11-011-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | set both `password` and `authentication_string` columns in `mysql`.`user` table for now. Suppress the "password was ignored" warning if the password is the same as the authentication string
* | | | | | MDEV-12023 Assertion failure sym_node->table != NULL on startupMarko Mäkelä2018-10-3010-0/+671
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | row_drop_table_for_mysql(): Avoid accessing non-existing dictionary tables. dict_create_or_check_foreign_constraint_tables(): Add debug instrumentation for creating and dropping a table before the creation of any non-core dictionary tables. trx_purge_add_update_undo_to_history(): Adjust a debug assertion, so that it will not fail due to the test instrumentation.
* | | | | | MDEV-17536 Merge new release of InnoDB 5.7.24 to 10.2Marko Mäkelä2018-10-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Update the InnoDB version number to 5.7.24.
* | | | | | MDEV-17548 Incorrect access to off-page column for indexed virtual columnMarko Mäkelä2018-10-252-0/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | row_build_index_entry_low(): ext does not contain virtual columns. row_upd_store_v_row(): Copy virtual column values This is based on the following fix in MySQL 5.7.24: commit 4ec2158bec73f1582501c4b3e3de250fed9edc9a Author: Sachin Agarwal <sachin.z.agarwal@oracle.com> Date: Fri Aug 24 14:44:13 2018 +0530 Bug #27968952 INNODB CRASH/CORRUPTION WITH TEXT PREFIX INDEXES Problem: There are two problems: 1. If there is one secondary index on extenally stored column and another seconday index on virtual column (whose base column is not externally stored). then while updating seconday index on vitrual column, virtual column data is replaced by externally stoared column. 2. In row update operation, node->row contains shallow copy of virtual data fields. While building an update vector containing all the fields to be modified, compute virtual column. which may causes change in virtual data fields in node->row. In both the above cases, while updating seconday index on virtual column, couldn't find the row and hit an explicite assert inside ROW_NOT_FOUND. Fix: 1. Added check if column is virtual then its ext flag should be ZERO and virtual column data will not be replaced by offset column data. 2. Deep copy of virtual data fields for node->row. RB: #20382 Reviewed by : Jimmy.Yang@oracle.com
* | | | | | Remove a deprecation warningMarko Mäkelä2018-10-252-4/+2
| | | | | |
* | | | | | MDEV-17541 KILL QUERY during lock wait in FOREIGN KEY check causes hangMarko Mäkelä2018-10-252-6/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | row_ins_check_foreign_constraint(): Do not overwrite hard errors with the soft error DB_LOCK_WAIT. This prevents an infinite wait loop when DB_INTERRUPTED was returned. For DB_LOCK_WAIT, row_insert_for_mysql() would keep invoking row_ins_step() and the transaction would remain active until the server shutdown is initiated.
* | | | | | MDEV-13564: Set innodb_safe_truncate=ON by defaultMarko Mäkelä2018-10-1710-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The setting innodb_safe_truncate=ON reduces compatibility with older versions of MariaDB and backup tools in two ways. First, we will be writing TRX_UNDO_RENAME_TABLE records, which older versions do not know about. These records could be misinterpreted if a DDL transaction was recovered and would be rolled back. Such rollback is only possible if the server was killed while an incomplete DDL transaction was persisted. On transaction completion, the insert_undo log pages would only be repurposed for new undo log allocations, and their contents would not matter. So, older versions will not have a problem with innodb_safe_truncate=ON if the server was shut down cleanly. Second, to prevent such recovery failure, innodb_safe_truncate=ON will cause a modification of the redo log format identifier, which will prevent older versions from starting up after a crash. MariaDB Server versions older than 10.2.13 will refuse to start up altogether, even after clean shutdown. A server restart with innodb_safe_truncate=OFF will restore compatibility with older server and backup versions.
* | | | | | MDEV-17098 DATE -> DATETIME replication conversion not working, even in ↵Andrei Elkin2018-10-162-0/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ALL_NON_LOSSY mode Opened up MYSQL_TYPE _DATETIME{,2} <-> _NEWDATE conversions for replication.
* | | | | | MDEV-17433 Allow InnoDB start up with empty ib_logfile0 from mariabackup ↵Marko Mäkelä2018-10-112-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --prepare A prepared backup from Mariabackup does not really need to contain any redo log file, because all log will have been applied to the data files. When the user copies a prepared backup to a data directory (overwriting existing files), it could happen that the data directory already contained redo log files from the past. mariabackup --copy-back) would delete the old redo log files, but a user’s own copying script might not do that. To prevent corruption caused by mixing an old redo log file with data files from a backup, starting with MDEV-13311, Mariabackup would create a zero-length ib_logfile0 that would prevent startup. Actually, there is no need to prevent InnoDB from starting up when a single zero-length file ib_logfile0 is present. Only if there exist multiple data files of different lengths, then we should refuse to start up due to inconsistency. A single zero-length ib_logfile0 should be treated as if the log files were missing: create new log files according to the configuration. open_log_file(): Remove. There is no need to open the log files at this point, because os_file_get_status() already determined the size of the file. innobase_start_or_create_for_mysql(): Move the creation of new log files a little later, not when finding out that the first log file does not exist, but after finding out that it does not exist or it exists as a zero-length file.
View Lorry Controller Status