- 15 Mar, 2018 6 commits
-
-
Jan Lindström authored
MDEV-13549 Fix and re-enable MTR test galera.MW-366
-
Jan Lindström authored
MDEV-13549 Fix and re-enable test galera.galera_bf_abort_for_update
-
Jan Lindström authored
MDEV-13549 Fix and re-enable test galera.MW-286
-
Daniele Sciascia authored
These tests were also subject to error "Wrong usage of mutex 'LOCK_wsrep_thd' and 'LOCK_thd_kill'".
-
Alexander Barkov authored
"mtr func_date_add" failed on 32-bit platforms. Removing a wrong case to "long". Both values[] and log_10_int[] are arrays of "ulonglong", no cast is needed.
-
Vicențiu Ciorbaru authored
-
- 14 Mar, 2018 5 commits
-
-
Timo Teräs authored
musl ships the header for other purposes, but makecontext is not implemented. fix the check to detect if makecontext is implemented before enabling code using it.
-
Alexander Barkov authored
-
Vicențiu Ciorbaru authored
-
Daniele Sciascia authored
Test passes reliably after applying missing commit from upstream.
-
Vasil Dimov authored
The test was not deterministic as it would not wait for the second INSERT to be applied (and thus the victim transaction rolled back).
-
- 13 Mar, 2018 2 commits
-
-
Daniele Sciascia authored
Test galera.MW-366 is not deterministic and depends on timing assumptions. The test occasionally fails after checking the number of 'system user' processes in processlist after changing the value of variable global wsrep_slave_threads, like this: ``` SET GLOBAL wsrep_slave_threads = x; --sleep 0.5 SELECT COUNT(*) = x FROM INFORMATION_SCHEMA.PROCESSLIST WHERE USER = 'system user'; ``` The problem is that the number of slave threads is internally adjusted 'asynchronously', and it may take some time to spawn/kill new threads, especially in a heavily loaded system. This patch removes the '--sleep 0.5' statements from the test and replaces those with appropriate wait conditions, like this: ``` SET GLOBAL wsrep_slave_threads = x; let $wait_condition = SLECT COUNT(*) = x FROM ...; --source include/wait_condition.inc ```
-
Alexander Barkov authored
-
- 12 Mar, 2018 4 commits
-
-
Andrei Elkin authored
replicate_events_marked_for_skip=FILTER_ON_MASTER [Note this is a cherry-pick from 10.2 branch.] When events of a big transaction are binlogged offsetting over 2GB from the beginning of the log the semisync master's dump thread lost such events. The events were skipped by the Dump thread that found their skipping status erroneously. The current fixes make sure the skipping status is computed correctly. The test verifies them simulating the 2GB offset.
-
Sergey Vojtovich authored
Based on contribution by Daniel Black.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
fts_sync(): If the dict_table_t::to_be_dropped flag is set, do not "goto begin_sync". Also, clean up the way how dict_index_t::index_fts_syncing is cleared. It looks like this regression was introduced by merging Oracle Bug #24938374 MYSQL CRASHED AFTER LONG WAIT ON DICT OPERATION LOCK WHILE SYNCING FTS INDEX https://github.com/mysql/mysql-server/commit/068f8261d4c1e134965383ff974ddf30c0758f51 from MySQL 5.6.38 into MariaDB 10.0.33, 10.1.29, 10.2.10. The same hang is present in MySQL 5.7.20.
-
- 11 Mar, 2018 1 commit
-
-
Varun Gupta authored
The issue is that we are creating a materialised table with key of length 0 which is incorrect, we should disable materialisation for such a case.
-
- 09 Mar, 2018 2 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
MDEV-14648 Restore fix for MySQL BUG#39053 - UNINSTALL PLUGIN does not allow the storage engine to cleanup open connections ha_close_connection(): Do invoke the method also for plugins for which UNINSTALL PLUGIN was deferred due to open connections.
-
- 08 Mar, 2018 2 commits
-
-
Daniele Sciascia authored
Test MW-286 occasionally failed with error the following message: ``` safe_mutex: Found wrong usage of mutex 'LOCK_wsrep_thd' and 'LOCK_thd_kill' Mutex currently locked (in reverse order): LOCK_thd_kill mariadb-server/sql/sql_class.h line 3535 LOCK_wsrep_thd mariadb-server/sql/wsrep_thd.cc line 88 ``` The fix consists in calling thd->reset_killed() in wsrep_mysql_parse() after LOCK_wsrep_thd is unlocked. Which avoids the taking locks LOCK_wsrep_thd and LOCK_thd_kill in reverse order.
-
Daniele Sciascia authored
This test failed to work properly because the fixes it came with were not merged from upstream. The test would fail with a spurious ER_LOCK_DEADLOCK error for a conflict that happened earlier in the test execution, while wsrep is disabled. The original fix was to set THD::wsrep_conflict_state only if wsrep is enabled (see wsrep_thd_set_conflict_state() in sql/wsrep_mysqld.cc)
-
- 07 Mar, 2018 1 commit
-
-
Marko Mäkelä authored
InnoDB in Debian uses utf8mb4 as default character set since version 10.0.20-2. This leads to major pain due to keys longer than 767 bytes. MariaDB 10.2 (and MySQL 5.7) introduced the setting innodb_default_row_format that is DYNAMIC by default. These versions also changed the default values of the parameters innodb_large_prefix=ON and innodb_file_format=Barracuda. This would allow longer column index prefixes to be created. The original purpose of these parameters was to allow InnoDB to be downgraded to MySQL 5.1, which is long out of support. Every InnoDB version since MySQL 5.5 does support operation with the relaxed limits. We backport the parameter innodb_default_row_format to MariaDB 10.1, but we will keep its default value at COMPACT. This allows MariaDB 10.1 to be configured so that CREATE TABLE is less likely to encounter a problem with the limitation: loose_innodb_large_prefix=ON loose_innodb_default_row_format=DYNAMIC (Note that the setting innodb_large_prefix was deprecated in MariaDB 10.2 and removed in MariaDB 10.3.) The only observable difference in the behaviour with the default settings should be that ROW_FORMAT=DYNAMIC tables can be created both in the system tablespace and in .ibd files, no matter what innodb_file_format has been assigned to. Unlike MariaDB 10.2, we are not changing the default value of innodb_file_format, so ROW_FORMAT=COMPRESSED tables cannot be created without changing the parameter.
-
- 04 Mar, 2018 1 commit
-
-
Sergei Golubchik authored
fix 50359719 don't rely on any specific engine checking order
-
- 24 Feb, 2018 2 commits
-
-
Daniel Black authored
-
Sergei Golubchik authored
prevents buffering in cases like ./mtr | tee log
-
- 22 Feb, 2018 3 commits
-
-
Sergei Golubchik authored
-
Jan Lindström authored
-
Sergei Golubchik authored
-
- 21 Feb, 2018 5 commits
-
-
Sergei Golubchik authored
despite the name, it logs both stdout and stderr
-
Sergei Golubchik authored
tokudb apparently requires perfschema now
-
Sergei Golubchik authored
-
Daniel Black authored
Analysis:- The problem is the change in the implementation of wait_for_listen in wsrep_sst_xtrabackup-v2.sh. The new script uses lsof which will always exit with an error code if it can't find all the items, and because the script has the -e option set in the hashbang line (#!/bin/bash -ue), the script will abort right after running lsof if lsof can't find even a single item among all the items listed in its arguments. This will happen even if socat is running and listening, because it can't find nc. The loop in wait_for_listen will therefore always quit after one iteration without writing the "ready" line to signal the parent. Solution:- We will or the lsof with true. Patch Credit :Daniel Black and David Wang
-
Sergei Golubchik authored
-
- 20 Feb, 2018 3 commits
-
-
Vladislav Vaintroub authored
a) We do not need this on Windows, and it is not clear what it does,inside service. b) It hinders debugging. mysql-test-run.pl --debugger=vsjitdebugger more often than , would stop here throwing "invalid handle" exception.
-
Jan Lindström authored
* galera_gtid_slave * galera_unicode_identifiers
-
Jan Lindström authored
-
- 19 Feb, 2018 2 commits
-
-
Sergey Vojtovich authored
Added missing include.
-
Jan Lindström authored
MDEV-14814: encryption.innodb_encryption-page-compression failed in buildbot with timeout on wait condition Test changes only.
-
- 18 Feb, 2018 1 commit
-
-
Jan Lindström authored
-