summaryrefslogtreecommitdiff
path: root/mysql-test
Commit message (Collapse)AuthorAgeFilesLines
* List of unstable tests for 10.2.35 releasemariadb-10.2.35Elena Stepanova2020-10-311-384/+352
|
* MDEV-24033: SIGSEGV in __memcmp_avx2_movbe from queue_insert | SIGSEGV in ↵Varun Gupta2020-10-302-0/+41
| | | | | | | | | | | | | | | __memcmp_avx2_movbe from native_compare The issue here was the system variable max_sort_length was being applied to decimals and it was truncating the value for decimals to the number of bytes set by max_sort_length. This was leading to a buffer overflow as the values were written to the buffer without truncation and then we moved the offset to the number of bytes(set by max_sort_length), that are needed for comparison. The fix is to not apply max_sort_length for fixed size types like INT, DECIMALS and only apply max_sort_length for CHAR, VARCHARS, TEXT and BLOBS.
* Fix sporadic test failure on galera_parallel_apply_3nodes.Jan Lindström2020-10-302-5/+23
| | | | Test itself is not deterministic.
* Merge branch '10.1' into 10.2Oleksandr Byelkin2020-10-2910-16/+23
|\
| * MDEV-23702 calculating(auto rounding) issueSergei Golubchik2020-10-297-17/+22
| | | | | | | | | | | | | | | | | | | | Implement a different fix for "MDEV-19232: Floating point precision / value comparison problem" Instead of truncating decimal values after every division, truncate them for comparison purposes. This reverts commit 62d73df6b270 but keeps the test.
| * update result files after backportSergei Golubchik2020-10-293-12/+0
| | | | | | | | followup for 3e807d255e0e and eae10a87ff60
| * Move result files at the correct place.Oleksandr Byelkin2020-10-293-0/+0
| |
* | remove non-working debug assertSergei Golubchik2020-10-291-2/+1
| | | | | | | | | | and restore the test modified in the same commit (the non-replication related deadlock will be reported separately)
* | MDEV-24026: InnoDB: Failing assertion: os_total_large_mem_allocated >= size ↵Vlad Lesin2020-10-292-1/+6
| | | | | | | | | | | | | | | | upon incremental backup mariabackup deallocated uninitialized write_filt_ctxt.u.wf_incremental_ctxt in xtrabackup_copy_datafile() when some table should be skipped due to parsed DDL redo log record.
* | MDEV-22707 : galera got stuck after flush tablesJan Lindström2020-10-281-0/+1
| | | | | | | | | | Remove unnecessary condition and add necessary include for non debug Galera library.
* | Merge branch '10.1' into 10.2Oleksandr Byelkin2020-10-2816-40/+431
|\ \ | |/
| * test case for BUG#31650096Sergei Golubchik2020-10-272-0/+34
| |
| * cleanup: have_static_innodb.incSergei Golubchik2020-10-274-14/+8
| | | | | | | | and remove unused files
| * Bug#31304432 "INSUFFICIENT PRIVILEGE CHECK BY LOCK TABLES"Sergei Golubchik2020-10-272-0/+292
| | | | | | | | | | | | | | `LOCK TABLES view_name` should require * invoker to have SELECT and LOCK TABLES privileges on the view * either invoker or definer (only if sql security definer) to have SELECT and LOCK TABLES privileges on the used tables/views.
| * Fix test failure on wsrep/variables test case.Jan Lindström2020-10-242-0/+10
| |
| * MDEV-24017: Blackhole : Specified key was too long; max key length is 1000 bytesVlad Lesin2020-10-242-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | The maximum innodb key length is 3500 what is hardcoded in ha_innobase::max_supported_key_length()). The maximum number of innodb indexes is configured with MAX_INDEXES macro (see also MAX_KEY definition). The same is currently implemented for blackhole storage engine. Cherry picked from percona-server 0d90d81c3c507a6b1476246a405504f6e4ef9d4d Original lp bug 1733049 Reviewed-by: daniel@mariadb.org
| * MDEV-20744 SET GLOBAL `replicate_do_db` = DEFAULT causes crash.bb-10.1-hfAlexey Botchkov2020-10-232-0/+7
| | | | | | | | DEFAULT for the replicate_do_db is the "" as our documentation states.
| * MDEV-10149: sys_vars.rpl_init_slave_func fails sporadically in buildbotSujatha2020-10-222-27/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | problem: ======== mysqltest: In included file "./include/assert.inc": included from mysql-test/suite/sys_vars/t/rpl_init_slave_func.test at line 69: Assertion text: '@@global.max_connections = @start_max_connections' Assertion result: '0' mysqltest: In included file "./include/assert.inc": included from mysql-test/suite/sys_vars/t/rpl_init_slave_func.test at line 86: Assertion text: '@@global.max_connections = @start_max_connections + 1' Assertion result: '0' Analysis: ========= A slave SQL thread sets its Running state to Yes very early in its initialisation, before the majority of initialisation actions, including executing the init_slave command, are done. Thus the testcase has a race condition where the initial replication setup might finish executing later than the testcase SET GLOBAL init_slave, making the testcase see its effect where it checks for its absence. Fix: === Include 'sync_slave_sql_with_master.inc' at the beginning of the test to ensure that slave applier has completed the execution of 'init_slave' command and proceeded to event application. Replace the apparently needless RESET MASTER / RESET SLAVE etc. Patch is based on: https://github.com/percona/percona-server/pull/1464/commits/b91e2e6f90611aa299c302929fb8b068e8ac0dee Author: laurynas-biveinis
* | MDEV-23991 dict_table_stats_lock() has unnecessarily long scopeEugene Kosov2020-10-272-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch removes dict_index_t::stats_latch. Table/index statistics now protected with dict_sys->mutex. That way statistics computation can happen in parallel in several threads and dict_sys->mutex will be locked only for a short period of time. This patch is a joint work with Marko Mäkelä dict_index_t::lock: make mutable which allows to pass const pointer when only lock is touched in an object btr_height_get() btr_get_size(): make index argument const for better type safety btr_estimate_number_of_different_key_vals(): now returns computed values instead of setting fields in dict_index_t directly remove everything related to dict_index_t::stats_latch dict_stats_index_set_n_diff(): now returns computed values instead of setting fields in dict_index_t directly dict_stats_analyze_index(): now returns computed values instead of setting fields in dict_index_t directly Reviewed by: Marko Mäkelä
* | MDEV-16952 Introduce SET GLOBAL innodb_max_purge_lag_waitMarko Mäkelä2020-10-272-16/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let us introduce a dummy variable innodb_max_purge_lag_wait for waiting that the InnoDB history list length is below the user-specified limit. Specifically, SET GLOBAL innodb_max_purge_lag_wait=0; should wait for all history to be purged. This could be useful when upgrading from an older version to MariaDB 10.3 or later, to avoid hitting MDEV-15912. Note: the history cannot be purged if there exist transactions that may see old versions. Reviewed by: Vladislav Vaintroub
* | MDEV-22524 SIGABRT in safe_mutex_unlock withAlexey Botchkov2020-10-272-0/+4
| | | | | | | | | | | | | | session_track_system_variables and max_relay_log_size. lock LOCK_global_system_variables around the get_one_variable() call in the Session_sysvars_tracker::store_variable().
* | MDEV-22707: galera got stuck after flush tablesmkaruza2020-10-272-0/+77
| | | | | | | | | | | | | | Deadlock is possible between applier thread and local committing thread with active FLUSH TABLE. Applier thread should skip table share checks and locks when opening table. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
* | remove disable_abort_on_error from precedence.testSergei Golubchik2020-10-252-17/+12
| | | | | | | | was left over from testing
* | MDEV-23720 Change innodb_log_optimize_ddl=OFF by defaultMarko Mäkelä2020-10-253-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MariaDB 10.2.2 inherited from MySQL 5.7 a perceived optimization of ALTER TABLE, which skips the writing of redo log records. In MDEV-16809 we introduced a parameter that allows the redo log to be written, so that Mariabackup would not be impacted, but we kept the MySQL 5.7 behaviour enabled by default (innodb_log_optimize_ddl=ON). As noted in MDEV-19747 (Deprecate and ignore innodb_log_optimize_ddl, implemented in MariaDB 10.5.1), omitting the redo log writes can actually reduce performance, because we will have to wait for the data pages to be written out. When the redo log file is configured to be large enough, it actually can be much faster to write the redo log and avoid the extra page flushing. When the redo log is omitted (innodb_log_optimize_ddl=ON), also Mariabackup may have to perform a lot of extra work, to re-copy the entire data file if it is possible that any log was omitted during the backup. Starting with MariaDB 10.5.1, the parameter innodb_log_optimize_ddl is deprecated and ignored. We hereby deprecate (but will not ignore) the parameter in earlier versions as well.
* | MDEV-22313: Neither SHOW CREATE USER nor SHOW GRANTS prints a user's default ↵Anel Husakovic2020-10-246-0/+58
| | | | | | | | | | | | role Reviewed-by: serg@mariadb.com
* | MDEV-23867: insert... select crash in compute_window_funcVarun Gupta2020-10-233-0/+3928
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are 2 issues here: Issue #1: memory allocation. An IO_CACHE that uses encryption uses a larger buffer (it needs space for the encrypted data, decrypted data, IO_CACHE_CRYPT struct to describe encryption parameters etc). Issue #2: IO_CACHE::seek_not_done When IO_CACHE objects are cloned, they still share the file descriptor. This means, operation on one IO_CACHE may change the file read position which will confuse other IO_CACHEs using it. The fix of these issues would be: Allocate the buffer to also include the extra size needed for encryption. Perform seek again after one IO_CACHE reads the file.
* | MDEV-17408 VIEW is incorrectly defined for a combination of = and BETWEENSergei Golubchik2020-10-232-0/+17
| |
* | precedence bugfixingSergei Golubchik2020-10-239-1413/+264
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fix printing precedence for BETWEEN, LIKE/ESCAPE, REGEXP, IN don't use precedence for printing CASE/WHEN/THEN/ELSE/END fix parsing precedence of BETWEEN, LIKE/ESCAPE, REGEXP, IN support predicate arguments for IN, BETWEEN, SOUNDS LIKE, LIKE/ESCAPE, REGEXP use %nonassoc for unary operators fix parsing of IS TRUE/FALSE/UNKNOWN/NULL remove parser_precedence test as superseded by the precedence test
* | cleanup: remove redundant BANG_PRECEDENCESergei Golubchik2020-10-231-1/+1
| | | | | | | | | | prefix unary operators don't need to have different precedence, the syntax unambiguously specifies in what order they apply
* | A fairly exhastive test for operator precedenceSergei Golubchik2020-10-232-0/+12893
| | | | | | | | some results are incorrect
* | cleanup: move precedence tests into precedence_bugs.testSergei Golubchik2020-10-238-51/+61
| |
* | MDEV-23656 view: removal of parentheses results in wrong resultSergei Golubchik2020-10-232-0/+23
| | | | | | | | Item_ref should have the precedence of the item it's referencing
* | MDEV-23492 performance_schema_digests_size changing from default to 5000 ↵Sergei Golubchik2020-10-232-2/+2
| | | | | | | | | | | | when enabling performance_schema max allowed value limit should be larger than any auto-sized value
* | MDEV-20755 InnoDB: Database page corruption on disk or a failed file read of ↵Vlad Lesin2020-10-233-0/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tablespace upon prepare of mariabackup incremental backup The problem: When incremental backup is taken, delta files are created for innodb tables which are marked as new tables during innodb ddl tracking. When such tablespace is tried to be opened during prepare in xb_delta_open_matching_space(), it is "created", i.e. xb_space_create_file() is invoked, instead of opening, even if a tablespace with the same name exists in the base backup directory. xb_space_create_file() writes page 0 header the tablespace. This header does not contain crypt data, as mariabackup does not have any information about crypt data in delta file metadata for tablespaces. After delta file is applied, recovery process is started. As the sequence of recovery for different pages is not defined, there can be the situation when crypt data redo log event is executed after some other page is read for recovery. When some page is read for recovery, it's decrypted using crypt data stored in tablespace header in page 0, if there is no crypt data, the page is not decryped and does not pass corruption test. This causes error for incremental backup --prepare for encrypted tablespaces. The error is not stable because crypt data redo log event updates crypt data on page 0, and recovery for different pages can be executed in undefined order. The fix: When delta file is created, the corresponding write filter copies only the pages which LSN is greater then some incremental LSN. When new file is created during incremental backup, the LSN of all it's pages must be greater then incremental LSN, so there is no need to create delta for such table, we can just copy it completely. The fix is to copy the whole file which was tracked during incremental backup with innodb ddl tracker, and copy it to base directory during --prepare instead of delta applying. There is also DBUG_EXECUTE_IF() in innodb code to avoid writing redo log record for crypt data updating on page 0 to make the test case stable. Note: The issue is not reproducible in 10.5 as optimized DDL's are deprecated in 10.5. But the fix is still useful because it allows to decrease data copy size during backup, as delta file contains some extra info. The test case should be removed for 10.5 as it will always pass.
* | MDEV-19443 server_audit plugin doesn't log proxy users.Alexey Botchkov2020-10-232-1/+75
| | | | | | | | PROXY_USER event added.
* | MDEV-20593 SIGSEGV in report_json_error_ex (on optimized builds).Alexey Botchkov2020-10-222-0/+6
| | | | | | | | | | | | When first argument to the JSON_MERGE_PATCH was NULL and second - the invalid JSON line, the error code was garbage. So it should be set to 0 initially.
* | Merge 10.1 into 10.2Marko Mäkelä2020-10-2128-18/+572
|\ \ | |/
| * InnoDB 5.6.50Marko Mäkelä2020-10-215-3/+44
| |\ | | | | | | | | | | | | The only applicable InnoDB change to MariaDB that was made between MySQL 5.6.49 and MySQL 5.6.50 is MDEV-23999.
| | * MDEV-23999 Potential stack overflow in InnoDB fulltext searchMarko Mäkelä2020-10-212-0/+41
| |/ | | | | | | | | | | | | | | | | | | | | | | | | fts_query_t::nested_sub_exp: Keep track of nested fts_ast_visit_sub_exp() calls. fts_ast_visit_sub_exp(): Return DB_OUT_OF_MEMORY if the maximum recursion depth is exceeded. This is motivated by a change in MySQL 5.6.50: mysql/mysql-server@e2a46b4834a0030e5380d45789772cb6beab6e92 Bug #29929684 USING MANY NESTED ARGUMENTS WITH BOOLEAN FTS CAN LEAD TO TERMINATE SERVER
| * Updated mtr helpAnel Husakovic2020-10-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Updated combination example to use `innodb_plugin` ``` $ ./mysql-test/mtr rpl.rpl_invoked_features # no rpl.rpl_invoked_features,mix,xtradb_plugin worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019 rpl.rpl_invoked_features 'innodb_plugin,mix' [ pass ] 904 rpl.rpl_invoked_features 'mix,xtradb' [ pass ] 1707 rpl.rpl_invoked_features 'innodb_plugin,row' [ pass ] 927 rpl.rpl_invoked_features 'row,xtradb' [ pass ] 828 rpl.rpl_invoked_features 'innodb_plugin,stmt' [ pass ] 855 rpl.rpl_invoked_features 'stmt,xtradb' [ pass ] 952 -------------------------------------------------------------------------- ``` - `gdb` option can take optional gdb arguments (good documentation in KB)
| * MDEV-5628: Assertion `! is_set()' or `!is_set() || (m_status == DA_OK_BULK &&Rucha Deodhar2020-10-202-0/+27
| | | | | | | | | | | | | | | | is_bulk_op())' fails on UPDATE on a partitioned table with subquery (MySQL:71630) Analysis and fix: Error is not checked. So correct error state is not returned. Fix: Check for error and return the error state.
| * MDEV-17729: Assertion `! is_set() || m_can_overwrite_status' failed inRucha Deodhar2020-10-202-0/+32
| | | | | | | | | | | | | | | | | | | | Diagnostics_area::set_error_status Analysis: When strict mode is enabled, all warnings are converted to errors including those which do not occur because of bad data. Fix: Query should not be aborted when we have warning because limit to examine rows was reached because it doesn't happen due to bad data. So thd->abort_on_warning should be false.
| * MDEV-23938: innodb row_search_idx_cond_check handle ICP_ABORTED_BY_USERSergei Petrunia2020-10-167-0/+162
| | | | | | | | | | | | | | | | | | | | | | | | | | | | - row_search_mvcc() should return DB_INTERRUPTED when it got killed. - Add a syncpoint for the ICP check. - Add test coverage for killed-during-ICP-check scenario Backport of MDEV-22761 fixes for ICP from 10.4 commits: * a6f956488c712bef3b13660584d1b905e0c676cc * c03885cd9ceb1ede7f49a9e218022b401b3a1e28 XtraDB was fixed in deb3b9a17498 Reviewer: Daniel Black
| * MDEV-23722 InnoDB: Assertion: result != FTS_INVALID in fts_trx_row_get_new_stateThirunarayanan Balathandayuthapani2020-10-084-0/+154
| | | | | | | | | | | | | | | | | | Marking of deletion of row in fts index happens twice in self-referential foreign key relation. So while performing referential checks of foreign key, InnoDB can avoid updating of fts index if the foreign key has self-referential relationship. Reviewed-by: Marko Mäkelä
| * MDEV-4851: (tests) log tables modifiable on log_output!=TABLEbb-10.1-danielblack-MDEV-4851Daniel Black2020-10-084-15/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | Test we can ALTER log tables directly when not being written to. This removes the contraint in the rpl_mysql_upgrade.test such that we can run mysql_upgrade --write-binlog all the way through to a replica. We test this in the replication scenario where the mysql.{slow,general}_log tables aren't being written to. Reviewers: Vicențiu Ciorbaru, Anel Husakovic
| * MDEV-23832 Crash at startup in Log_event::read_log_eventAndrei Elkin2020-10-072-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | The crash was caused by improper raising of an error or replication checksum verification at time of the server initialization. As there is no THD object associated with the main initializing thread yet the error text should be assigned with calling a respective macro that is aware of that possibility. Fixed accordingly. [At merging to 10.4 the new test result file needs +# restart: --master_verify_checksum=ON --debug_dbug=+d,corrupt_read_log_event_char that mtr run will hint on.]
| * mtr: innodb_stats_dropped_locked cleanupbb-10.1-danielblack-test-innodb_stats_drop_locked_cleanupDaniel Black2020-10-012-0/+4
| | | | | | | | | | | | As discovered in later test, this test doesn't remove the innodb_{index,table}_stats entries generated in the test upon completion.
* | Update mtr helpAnel Husakovic2020-10-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Based on patch: d6a983351c5a454bd0cb113852f - Update combination example for 10.2 (commit 2a3fe45dd2df added change for 10.3+) ``` ============================================================================== TEST RESULT TIME (ms) or COMMENT -------------------------------------------------------------------------- worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019 rpl.rpl_invoked_features 'innodb,mix' [ pass ] 1677 rpl.rpl_invoked_features 'innodb,row' [ pass ] 3516 rpl.rpl_invoked_features 'innodb,stmt' [ pass ] 1609 -------------------------------------------------------------------------- ``` - `gdb` option will be added during the merge
* | MDEV-21951: mariabackup SST fail if data-directory have lost+found directoryJulius Goryavsky2020-10-203-0/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | To fix this, it is necessary to add an option to exclude the database with the name "lost+found" from processing (the database name will be checked by the check_if_skip_database_by_path() or by the check_if_skip_database() function, and as a result "lost+found" will be skipped). In addition, it is necessary to slightly modify the verification logic in the check_if_skip_database() function. Also added a new test galera_sst_mariabackup_lost_found.test
* | MDEV-23387 dict_load_foreign() fails to load the table during alterThirunarayanan Balathandayuthapani2020-10-192-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: ======= InnoDB allows virtual index to be referenced index in foreign key relations. While dropping the virtual column, Inplace alter does allow the table to be closed and open it using table name to update dict_table_t::v_cols. While loading the table, it doesn't allow any error to be ignored. InnoDB can't find the referenced virtual index and fails to load the table during Inplace alter. Solution: ========= During inplace alter, ignore the foreign key error while loading the table. Reviewed-by: Marko Mäkelä
View Lorry Controller Status