- 18 Dec, 2019 2 commits
-
-
Sergei Petrunia authored
Remove Query_tables_list::lock_tables_state - it is not used and it causes errors like this: sql_lex.h:1675:7: runtime error: load of value 2779096485, which is not a valid value for type 'enum_lock_tables_state'
-
Sergei Petrunia authored
Fix wrong typecast
-
- 16 Dec, 2019 2 commits
-
-
Alexander Barkov authored
-
Alexander Barkov authored
-
- 13 Dec, 2019 2 commits
-
-
Sergei Golubchik authored
crashes on Debian 10
-
Sergei Golubchik authored
-
- 11 Dec, 2019 2 commits
-
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
-
- 06 Dec, 2019 1 commit
-
-
Sujatha authored
Problem: ======= Test "binlog.binlog_parallel_replication_marks_row" fails sporadically due to result length mismatch. Analysis: ========= Test generates a binary log and it looks for certain words within the binary log file and prints them. For example word like "GTID,BEGIN,COMMIT ...". Binary log output contains base64 encoded characters. Occasionally the encoded characters match with the above words and results in test failure. +XwoFWxMBAAAALgAAAGEDAAAAAB8AAAAAAAEABHRlc3QAAnQxAAIDAwACFGTIDQ== +AAAAAAAAAAAEEwQADQgICAoKCgGTIDw9 Fix: === Improve the regular expression to match exact words.
-
- 05 Dec, 2019 4 commits
-
-
Eugene Kosov authored
Let MTR check for error existence after running a test and return it back to user. Error reporting itset might be much better, but first of all we need to see that something went wrong.
-
Jan Lindström authored
wsrep_on parameter can be visible even when wsrep_on is set OFF so we need to check variable_value from I_S also.
-
Axel Schwenke authored
-
Axel Schwenke authored
Set an explicit start and stop timeout of 900 seconds for the MariaDB Server systemd service
-
- 04 Dec, 2019 2 commits
-
-
Elena Stepanova authored
-
Axel Schwenke authored
Set an explicit start and stop timeout of 900 seconds for the MariaDB Server systemd service
-
- 03 Dec, 2019 3 commits
-
-
Vladislav Vaintroub authored
It is C++, not Java, the order of includes is often important.
-
Vladislav Vaintroub authored
It is C++, not Java, the order of includes is often important.
-
Oleksandr Byelkin authored
-
- 02 Dec, 2019 2 commits
-
-
Anel Husakovic authored
-
Faustin Lammler authored
The lintian Debian tool is complaining about: 'W: mariadb-test: manpage-has-errors-from-man usr/share/man/man1/mysql-test-run.pl.1.gz 246: warning [p 2, 6.0i, div '3tbd1,1', 0.3i]: can't break line' See: https://salsa.debian.org/faust-guest/mariadb-10.3/-/jobs/431900 The following command permits to catch the problematic lines: $ groff -man -Tascii ./mysql-test-run.pl.1 | less Closes #1419
-
- 30 Nov, 2019 2 commits
-
-
Eugene Kosov authored
-
Eugene Kosov authored
-
- 29 Nov, 2019 2 commits
-
-
Anel Husakovic authored
-
Daniel Black authored
$glob_mysql_test_dir was the wrong directory for strace output as it was for in-tree builds only so failed for: * out of tree builds * --parallel; and * --mem strace output wasn't saved. strace-option never replaced existing arguments (so ammended documentation). strace-client didn't accept an argument as described. Replaced specification of client with this with 'stracer' to be consistent with --debugger option. For consistency with debugger options, --client-strace was added to execute the strace on the mysqltest. Example: Running one test $ ./mtr --strace --client-strace funcs_1.is_table_constraints Logging: ./mtr --strace --client-strace funcs_1.is_table_constraints vardir: /home/anel/mariadb/5.5/mysql-test/var Checking leftover processes... Removing old var directory... - WARNING: Using the 'mysql-test/var' symlink Creating var directory '/home/anel/mariadb/5.5/mysql-test/var'... Checking supported features... MariaDB Version 5.5.67-MariaDB-debug Installing system database... - SSL connections supported - binaries are debug compiled Collecting tests... ============================================================================== TEST RESULT TIME (ms) or COMMENT -------------------------------------------------------------------------- worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019 funcs_1.is_table_constraints [ pass ] 1270 -------------------------------------------------------------------------- The servers were restarted 0 times Spent 1.270 of 3 seconds executing testcases Completed: All 1 tests were successful $ find -L . -name \*strace -ls 653 56 -rw-r--r-- 1 anel anel 57147 Nov 29 15:08 ./var/log/mysqltest.strace 646 1768 -rw-r--r-- 1 anel anel 1809855 Nov 29 15:08 ./var/log/mysqld.1.strace Example: Running test in parallel $ mysql-test/mtr --strace --client-strace --mem --parallel=3 main.select Logging: /home/dan/software_projects/mariadb-server/mysql-test/mysql-test-run.pl --strace --client-strace --mem --parallel=3 main.select vardir: /home/dan/software_projects/build-mariadb-10.3/mysql-test/var Checking leftover processes... Removing old var directory... Creating var directory '/home/dan/software_projects/build-mariadb-10.3/mysql-test/var'... - symlinking 'var' to '/dev/shm/var_auto_0v2E' Checking supported features... MariaDB Version 5.5.67-MariaDB - SSL connections supported Collecting tests... Installing system database... ============================================================================== TEST WORKER RESULT TIME (ms) or COMMENT -------------------------------------------------------------------------- worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019 worker[3] - 'localhost:16040' was not free worker[2] Using MTR_BUILD_THREAD 301, with reserved ports 16020..16039 worker[3] Using MTR_BUILD_THREAD 303, with reserved ports 16060..16079 main.select w1 [ pass ] 7310 -------------------------------------------------------------------------- The servers were restarted 0 times Spent 7.310 of 11 seconds executing testcases Completed: All 1 tests were successful. $ find mysql-test/var/ -name \*strace -ls 5213766 1212 -rw-r--r-- 1 dan dan 1237817 May 20 16:47 mysql-test/var/1/log/mysqltest.strace 5214733 13016 -rw-r--r-- 1 dan dan 13328335 May 20 16:47 mysql-test/var/1/log/mysqld.1.strace $ mysql-test/mtr --strace --client-strace --strace-option='-e' --strace-option='trace=openat' --mem --parallel=3 main.select ... $ find mysql-test/var/ -name \*strace -ls 5220790 8 -rw-r--r-- 1 dan dan 6291 May 20 17:02 mysql-test/var/3/log/mysqltest.strace 5224140 308 -rw-r--r-- 1 dan dan 314356 May 20 17:02 mysql-test/var/3/log/mysqld.1.strace $ more mysql-test/var/3/mysqltest.strace 1692 openat(AT_FDCWD, "/home/dan/software_projects/mariadb-server/libmysql/.libs/tls/x86_64/x86_64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 1692 openat(AT_FDCWD, "/home/dan/software_projects/mariadb-server/libmysql/.libs/tls/x86_64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOE NT (No such file or directory) Closes #600
-
- 28 Nov, 2019 1 commit
-
-
Eugene Kosov authored
init_settings.keywords and it's pointee are shared data. Protect them with mutex too.
-
- 26 Nov, 2019 5 commits
-
-
Vicențiu Ciorbaru authored
-
Vicențiu Ciorbaru authored
The required dependencies should be added through the autobake script, to also cover distributions that do not support libcrack2.
-
Vicențiu Ciorbaru authored
-
Seth Shelnutt authored
-
seppo authored
The problem happens when MariaDB master replicates writes for only non InnoDB tables (e.g. writes to MyISAM table(s)). Async slave node, in Galera cluster, can apply these writes successfully, but it will, in the end, write gtid position in mysql.gtid_slave_pos table. mysql.gtid_slave_pos table is InnoDB engine, and this write makes innodb handlerton part of the replicated "transaction". Note that wsrep patch identifies that write to gtid_slave_pos should not be replicated and skips appending wsrep keys for these writes. However, as InnoDB was present in the transaction, and there are replication events (for MyISAM table) in transaction cache, but there are no appended keys, wsrep raises an error, and this makes the söave thread to stop. The fix is simply to not treat it as an error if async slave tries to replicate a write set with binlog events, but no keys. We just skip wsrep replication and return successfully. This commit contains also a mtr test which forces mysql.gtid_slave_pos table isto be of InnoDB engine, and executes MyISAM only write through asyn replication. There is additional fix for declaring IO and background slave threads as non wsrep. These threads should not write anything for wsrep replication, and this is just a safeguard to make sure nothing leaks into cluster from these slave threads.
-
- 22 Nov, 2019 1 commit
-
-
Hashir Sarwar authored
Closes #1403
-
- 21 Nov, 2019 1 commit
-
-
Eugene Kosov authored
DbugParse(): removed mutex lock/unlock which should protect file writes only. And no file writes happen in this function. DbugFlush(): move mutex_unlock out of this method because fflush() doesn't need any locking. Slow stuff like mutex lock/unlock and accessing errno (TLS) is moved to a more narrow scope.
-
- 19 Nov, 2019 1 commit
-
-
Eugene Kosov authored
-
- 18 Nov, 2019 3 commits
-
-
Jan Lindström authored
-
seppo authored
This PR contains a mtr test for reproducing a failure with replicating create table as select statement (CTAS) through asynchronous mariadb replication to mariadb galera cluster. The problem happens when CTAS replication contains both create table statement followed by row events for populating the table. In such situation, the galera node operating as mariadb replication slave, will first replicate only the create table part into the cluster, and then perform another replication containing both the create table and row events. This will lead all other nodes to fail for duplicate table create attempt, and crash due to this failure. PR contains also a fix, which identifies the situation when CTAS has been replicated, and makes further scan in async replication stream to see if there are following row events. The slave node will replicate either single TOI in case the CTAS table is empty, or if CTAS table contains rows, then single bundled write set with create table and row events is replicated to galera cluster. This fix should keep master server's GTID's for CTAS replication in sync with GTID's in galera cluster.
-
Varun Gupta authored
Make sure that the sort buffers can store atleast one sort key. This is needed to make sure that all merge buffers are read else with no sort keys some merge buffers are skipped because the code makes a conclusion there is no data to be read.
-
- 14 Nov, 2019 1 commit
-
-
Daniel Black authored
Closes #1106
-
- 12 Nov, 2019 1 commit
-
-
Sujatha authored
Problem: ======== CURRENT_TEST: binlog_encryption.rpl_corruption mysqltest: In included file "./include/wait_for_slave_io_error.inc": ... At line 72: Slave stopped with wrong error code **** Slave stopped with wrong error code: 1743 (expected 1595,1913) **** Analysis: ======== The test emulates the corruption at the various stages of replication for example in binlog file, in network and in relay log etc. It verifies that all corruption cases are handled through appropriate error messages. The test cases which emulate network failure expect following errors. --ER_SLAVE_RELAY_LOG_WRITE_FAILURE (1595) --ER_NETWORK_READ_EVENT_CHECKSUM_FAILURE (1743) Ideally test should expect error codes as 1595 and 1743. But the test actually waits on incorrect error code 1595,1913 Fix: === Added appropriate error code for 'ER_NETWORK_READ_EVENT_CHECKSUM_FAILURE'. Replaced 1913 with 1743.
-
- 10 Nov, 2019 1 commit
-
-
Andrei Elkin authored
MDEV-19376 Repl_semi_sync_master::commit_trx assertion failure: ... || !m_active_tranxs->is_tranx_end_pos(trx_wait_binlog_name, trx_wait_binlog_pos) The assert indicates that the current transaction got caught uncleaned from the semisync master's cache when it is signaled to proceed upon its ack receive. The reason of missed cleanup turns out to be a flaw in the gtid connect mode. A submitted by connecting slave value of its last received event's binlog file *name* was adopted into {{Repl_semi_sync_master::m_reply_file_name}} as a part of semisync initialization. Notice that the initialization still refines the position part of the submitted last received event's binlog coordinates. The master side binlog filename:pos refinement is specific to the gtid connect mode for purpose of computing the latest binlog file to resume slave feeding from. Effectively in the gtid connect mode the computed resumption filename:pos may appear smaller in which case a new post-connect time committing transaction may be logged with its filename:pos also less than the submitted coordinates and that triggers the assert. Fixed with making the semisync initialization to use the refined filename:pos. It is guaranteed to be less than any new generated transaction's binlog:pos.
-
- 08 Nov, 2019 1 commit
-
-
Daniel Bartholomew authored
-