- 14 Sep, 2018 3 commits
-
-
Jan Lindström authored
MDEV-14143: galera.galera_kill_smallchanges, galera.galera_kill_ddl fail in buildbot with "Last Applied Action message in non-primary configuration from member 0" Add supression.
-
Jan Lindström authored
and debug builds. Modified version for 10.1 from following commit: commit 8e688764 Author: Oleksandr Byelkin <sanja@mariadb.com> Date: Thu Sep 13 15:06:44 2018 +0200 Fix of the test which has debug version
-
Jan Lindström authored
Move MW-328[A,B,C] to big tests as there seem to be big variation on their execution times and sometimes that could lead timeout.
-
- 13 Sep, 2018 4 commits
-
-
Jacob Mathew authored
The problem occurs in 10.2 and earlier releases of MariaDB Server because the Partition Engine was not pushing the engine conditions to the underlying storage engine of each partition. This caused Spider to return the first 5 rows in the table with the data provided by the customer. 2 of the 5 rows did not qualify the WHERE clause, so they were removed from the result set by the server. To fix the problem, I have back-ported support for engine condition pushdown in the Partition Engine from MariaDB Server 10.3. Author: Jacob Mathew. Reviewer: Kentoku Shiba. Cherry-Picked: Commit eb2ca3d4 on branch bb-10.2-MDEV-16912
-
Oleksandr Byelkin authored
-
Jan Lindström authored
MDEV-17173: correct parsing of 12.13.14.15:4444/xtrabackup_sst leavin…
-
Daniel Black authored
Correcting commit e78e308e $ . scripts/wsrep_sst_common.sh --address 12.13.14.15:4444/xtrabackup_sst ; set | grep WSREP_SST WSREP_SST_OPT_ADDR=12.13.14.15:4444/xtrabackup_sst WSREP_SST_OPT_ADDR_PORT=4444 WSREP_SST_OPT_AUTH= WSREP_SST_OPT_BINLOG= WSREP_SST_OPT_BINLOG_INDEX= WSREP_SST_OPT_BYPASS=0 WSREP_SST_OPT_CONF=' ' WSREP_SST_OPT_DATA= WSREP_SST_OPT_DEFAULT= WSREP_SST_OPT_EXTRA_DEFAULT= WSREP_SST_OPT_HOST=12.13.14.15 WSREP_SST_OPT_HOST_UNESCAPED=12.13.14.15 WSREP_SST_OPT_LSN= WSREP_SST_OPT_MODULE=xtrabackup_sst WSREP_SST_OPT_PATH=xtrabackup_sst WSREP_SST_OPT_PORT=4444 WSREP_SST_OPT_PSWD= WSREP_SST_OPT_SST_VER= WSREP_SST_OPT_SUFFIX_DEFAULT= WSREP_SST_OPT_SUFFIX_VALUE= WSREP_SST_OPT_USER= . scripts/wsrep_sst_common.sh --address 12.13.14.15:4444/xtrabackup_sst/1234/5676 ; set | grep WSREP_SST WSREP_SST_OPT_ADDR=12.13.14.15:4444/xtrabackup_sst/1234/5676 WSREP_SST_OPT_ADDR_PORT=4444 WSREP_SST_OPT_AUTH= WSREP_SST_OPT_BINLOG= WSREP_SST_OPT_BINLOG_INDEX= WSREP_SST_OPT_BYPASS=0 WSREP_SST_OPT_CONF=' ' WSREP_SST_OPT_DATA= WSREP_SST_OPT_DEFAULT= WSREP_SST_OPT_EXTRA_DEFAULT= WSREP_SST_OPT_HOST=12.13.14.15 WSREP_SST_OPT_HOST_UNESCAPED=12.13.14.15 WSREP_SST_OPT_LSN=1234 WSREP_SST_OPT_MODULE=xtrabackup_sst WSREP_SST_OPT_PATH=xtrabackup_sst/1234/5676 WSREP_SST_OPT_PORT=4444 WSREP_SST_OPT_PSWD= WSREP_SST_OPT_SST_VER=5676 WSREP_SST_OPT_SUFFIX_DEFAULT= WSREP_SST_OPT_SUFFIX_VALUE= WSREP_SST_OPT_USER=
-
- 12 Sep, 2018 6 commits
-
-
Jan Lindström authored
Test requires galera library version 25.3.24.
-
Sergei Petrunia authored
The bug was this scenario: 1. Join optimizer picks a range plan on index IDX1 (This index doesn't match the ORDER BY clause, so sorting will be needed) 2. Index Condition Pushdown pushes a part of WHERE down. The pushed condition is removed from SQL_SELECT::cond 3. test_if_skip_sort_order() figures that it's better to use IDX2 (as it will match ORDER BY ... LIMIT and so will execute faster) 3.1 It sees that there was a possible range access on IDX2. It tries to construct it by calling SQL_SELECT::test_quick_select(), but alas, SQL_SELECT::cond doesn't have all parts of WHERE anymore. So it uses full index scan which is slow. (The execution works fine because there's code further in test_if_skip_sort_order() which "Unpushes" the index condition and restores the original WHERE clause. It was just the test_quick_select call that suffered).
-
Jan Lindström authored
-
Jan Lindström authored
Add suppression.
-
Jan Lindström authored
MDEV-13743: galera_toi_truncate may fail with: query 'reap' succeeded - should have failed with errno 1213 Replace sleep with debug sync point before insert commit to make sure insert is not executed before truncate has started.
-
mkaruza authored
While executing CTAS galera applier thread can cause CTAS to abort and rollback. Rollback can take time causing applier thread to shutdown node after serial unsuccessful retries to apply transaction. Don't set lock_wait_timeout to zero to wait for lock.
-
- 11 Sep, 2018 2 commits
-
-
Vladislav Vaintroub authored
On Unix, it is compiled-in datadir value. On Windows, the directory is ..\data, relative to directory mariabackup.exe server uses the same logic to determine datadir.
-
Jan Lindström authored
Add missing test case with proper wait conditions for expected node contents.
-
- 10 Sep, 2018 1 commit
-
-
Jan Lindström authored
Add wait_conditions to wait expected node contents.
-
- 09 Sep, 2018 1 commit
-
-
Jan Lindström authored
Start general log OFF and then truncate mysql.general_log and use proper wait timeouts to make sure it is really empty.
-
- 08 Sep, 2018 2 commits
-
-
Daniel Bartholomew authored
-
Jan Lindström authored
-
- 07 Sep, 2018 7 commits
-
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Elena Stepanova authored
-
Sergei Golubchik authored
-
Jan Lindström authored
Test changes only.
-
Sergei Golubchik authored
-
Jan Lindström authored
galera library used.
-
- 06 Sep, 2018 7 commits
-
-
Oleksandr Byelkin authored
-
Oleksandr Byelkin authored
-
Sergei Golubchik authored
don't create static objects that destroy mutexes from destructors, and don't destroy mutexes from .so destructor (on-unload) function. if it happens after exit(), P_S will be long gone by that time this fixes tokudb tests crashing on quantal-amd64
-
Oleksandr Byelkin authored
-
Jan Lindström authored
-
Jan Lindström authored
MDEV-17058: Test failure on wsrep.variables MDEV-17060: Test failure on galera.galera_var_slave_threads Fix incorrect calculation of increased applier (slave) threads. Note that increase change takes effect "immediately" but we should use proper wait condition to wait it. Reducing the number of slave threads is not immediate as thread will only exit after a replication event.
-
Jan Lindström authored
MDEV-10756: wsrep_sst_xtrabackup-v2 does not support innodb_data_home_dir
-
- 05 Sep, 2018 4 commits
-
-
Sergei Golubchik authored
MDEV-16465 Invalid (old?) table or database name or hang in ha_innobase::delete_table and log semaphore wait upon concurrent DDL with foreign keys lowercase db and table names before prelocking. Post-fix for 9180e866 This fixes failures on main.lowercase_table4 on Windows
-
Sergey Vojtovich authored
for blob column Moved delete_stat_values_for_table_share() call to proper place.
-
Jan Lindström authored
-
Jan Lindström authored
Problem was that in SST log_bin_index name and directory was not handled and passed to rsync SST script. wsrep_sst_common.sh Read binlog index dirname and filename if --binlog-index parameter is provided. Read binlog filenames from that file from donor and write transfered binlog filenames to that file in joiner. mysqld.cc, mysqld.h Moved opt_binlog_index_name from static to global and added it to extern. wsrep_sst.cc generate_binlog_index_opt_val New function to generate binlog index name if opt_binlog_index_name is given on configuration. sst_prepare_other Add binlog index configuration to SST command. wsrep_sst.h Add new SST parameter --binlog-index Add test case.
-
- 04 Sep, 2018 3 commits
-
-
Marko Mäkelä authored
The regression that was introduced in commit 723f87e9 was fixed as part of MDEV-13333 (commit 3b37edee) without a test case, because the MDEV-13333 test case is even less deterministic than these ones.
-
Sergei Golubchik authored
-
Sergei Golubchik authored
MDEV-16465 Invalid (old?) table or database name or hang in ha_innobase::delete_table and log semaphore wait upon concurrent DDL with foreign keys Disable "Invalid (old?) table or database name" warning when converting table names in InnoDB's get_foreign_key_info(). Because a name can be a temporary table name during the ALTER TABLE, and some other thread can do SHOW CREATE TABLE for the other table in the FK relationships _anytime_.
-