summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-17571 Make systemd timeout behavior more compatible with long Galera SSTsbb-10.1-MDEV-17571Axel Schwenke2019-12-042-0/+14
| | | | | Set an explicit start and stop timeout of 900 seconds for the MariaDB Server systemd service
* .clang-format - do not sort include files.Vladislav Vaintroub2019-12-031-0/+1
| | | | It is C++, not Java, the order of includes is often important.
* .clang-format - do *not* sort include filesVladislav Vaintroub2019-12-031-1/+0
| | | | It is C++, not Java, the order of includes is often important.
* Merge branch '5.5' into 10.1Oleksandr Byelkin2019-12-035-28/+34
|\
| * Using `variables` instead of `values` in mysqld --help documentation would ↵Anel Husakovic2019-12-023-3/+3
| | | | | | | | be more accurate
| * Update `stracer` description in `mtr`. `strace-client` is not usedAnel Husakovic2019-11-291-1/+1
| |
| * MDEV-15503: mtr fix --straceDaniel Black2019-11-291-21/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | $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
| * Fixed some typos in mysql.ccHashir Sarwar2019-11-221-3/+3
| | | | | | | | Closes #1403
* | Fix the line break warning (groff/lintian).Faustin Lammler2019-12-021-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | cleanup: replace exit(1) with abort()Eugene Kosov2019-11-301-3/+3
| |
* | InnoDB: log unsuccessful calls to pthread_attr_init() and pthread_create() ↵Eugene Kosov2019-11-301-2/+12
| | | | | | | | before crash
* | try to fix data races in DBUGEugene Kosov2019-11-281-2/+40
| | | | | | | | | | init_settings.keywords and it's pointee are shared data. Protect them with mutex too.
* | cracklib-runtime needs a comma after to parse properlyVicențiu Ciorbaru2019-11-261-1/+1
| |
* | MDEV-13288: Proper fix for cracklib-runtimeVicențiu Ciorbaru2019-11-262-2/+1
| | | | | | | | | | The required dependencies should be added through the autobake script, to also cover distributions that do not support libcrack2.
* | MDEV-13288: Upstream debian patchVicențiu Ciorbaru2019-11-261-0/+1
| |
* | Fix incorrect DBUG_ENTER message for join_read_lastSeth Shelnutt2019-11-261-1/+1
| |
* | MDEV-19572 async slave node fails to apply MyISAM only writes (#1418)seppo2019-11-265-2/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | cleanup DBUGEugene Kosov2019-11-211-39/+28
| | | | | | | | | | | | | | | | | | | | | | 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.
* | cleanup: remove always true condition to fix clang warningEugene Kosov2019-11-191-1/+1
| |
* | Remove excessive sleep from test.Jan Lindström2019-11-181-1/+1
| |
* | MDEV-18497 CTAS async replication from mariadb master crashes galera nodes ↵seppo2019-11-186-1/+156
| | | | | | | | | | | | | | | | | | | | (#1410) 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.
* | MDEV-21044: Wrong result when using a smaller size for sort bufferVarun Gupta2019-11-183-0/+47
| | | | | | | | | | | | | | 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.
* | systemd: mariadb@bootstrap doesn't bootstrap, galera_new_cluster doesDaniel Black2019-11-141-1/+1
| | | | | | | | Closes #1106
* | MDEV-20953: binlog_encryption.rpl_corruption failed in buildbot due to wrong ↵Sujatha2019-11-123-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | error code 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.
* | MDEV-19376 Repl_semi_sync_master::commit_trx assertion failure: ... || ↵Andrei Elkin2019-11-103-1/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | !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.
* | bump the VERSIONDaniel Bartholomew2019-11-081-1/+1
| |
* | MDEV-20981 wsrep_sst_mariabackup fails silently when mariabackup is not ↵Hartmut Holzgraefe2019-11-081-0/+7
| | | | | | | | | | | | installed (#1406) Make sure failure to find mariabackup binary does not terminate the script silently, terminate with a clear error message instead
* | MDEV-20519: Query plan regression with optimizer_use_condition_selectivity > 1Varun Gupta2019-11-076-4/+166
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The issue here is the wrong estimate of the cardinality of a partial join, the cardinality is too high because the function table_cond_selectivity() returns an absurd number 100 while selectivity cannot be greater than 1. When accessing table t by outer reference t1.a via index we do not perform any range analysis for t. Yet we see TABLE::quick_key_parts[key] and TABLE->quick_rows[key] contain a non-zero value though these should have been remained untouched and equal to 0. Thus real cause of the problem is that TABLE::init does not clean the arrays TABLE::quick_key_parts[] and TABLE::>quick_rows[]. It should have done it because the TABLE structure created for any instance of a table can be reused for many queries.
* | Merge 5.5 into 10.1mariadb-10.1.43Marko Mäkelä2019-11-062-15/+14
|\ \ | |/
| * bump the VERSIONDaniel Bartholomew2019-11-051-1/+1
| |
| * MDEV-20971 ASAN heap-use-after-free in list_delete / heap_closeSergei Golubchik2019-11-042-15/+14
| | | | | | | | | | | | | | | | | | | | Don't save/restore HP_INFO as it could be changed by a concurrent thread. different parts of HP_INFO are protected by different mutexes and the mutex that protect most of the HP_INFO does not protect its open_list data. As a bonus, make heap_check_heap() to take const HP_INFO* and not make any changes there whatsoever.
* | MDEV-20987 InnoDB fails to start when fts table has FK relationThirunarayanan Balathandayuthapani2019-11-064-32/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | InnoDB: Assertion failure in file .../dict/dict0dict.cc line ... InnoDB: Failing assertion: table->can_be_evicted This fixes a regression that was caused by the fix of MDEV-20621 (commit a41d429765c7ddb528b9b438c68b25ff55d3bd55). MySQL 5.6 (and MariaDB 10.0) introduced eviction of tables from the InnoDB data dictionary cache. Tables that are connected to FOREIGN KEY constraints or FULLTEXT INDEX are exempt of the eviction. With the problematic change, a table that would already be exempt from eviction due to FOREIGN KEY would cause the problem if there also was a FULLTEXT INDEX defined on it. dict_load_table(): Only prevent eviction if table->can_be_evicted holds.
* | bump the VERSIONDaniel Bartholomew2019-11-051-1/+1
| |
* | Fix ninja buildVladislav Vaintroub2019-11-051-1/+2
| | | | | | | | | | Do not rely on existence of CMakeFiles/${target}.dir directory existence It is not there for custom targets in Ninja build.
* | Fix GCC 9.2.1 -Wstringop-truncationMarko Mäkelä2019-11-045-11/+8
| | | | | | | | | | | | | | | | | | dict_table_rename_in_cache(): Use strcpy() instead of strncpy(), because they are known to be equivalent in this case (the length of old_name was already validated). mariabackup: Invoke strncpy() with one less than the buffer size, and explicitly add NUL as the last byte of the buffer.
* | Fix build on !glibc/powerpc*pkubaj2019-11-021-1/+1
| | | | | | Do the same that newer branches do and don't include glibc-related headers on non-glibc environment.
* | MDEV-20424: New default value for optimizer_use_condition-selectivity leads ↵Varun Gupta2019-11-014-0/+146
| | | | | | | | | | | | | | | | to bad plan In the function prev_record_reads where one finds the different row combinations for a subset of partial join, it did not take into account the selectivity of tables involved in the subset of partial join.
* | MDEV-17896 Assertion `pfs->get_refcount() > 0' failedRobert Bindar2019-11-013-0/+71
| | | | | | | | | | | | Unfortunate DROP TEMPORARY..IF EXISTS on a regular table may allow subsequent CREATE TABLE statements to steal away the PFS_table_share instance from the dropped table.
* | List of unstable tests for 10.1.42 releasemariadb-10.1.42Elena Stepanova2019-10-311-123/+81
| |
* | MDEV-20927: Remove duplicated codeMarko Mäkelä2019-10-312-62/+0
| | | | | | | | | | | | In commit d1e6b0bcff0148f474e38002d5c1198726fe7970 some code was supposed to be modified, but instead it got duplicated. Remove the duplicated copy.
* | cleanupSergei Golubchik2019-10-301-8/+3
| | | | | | | | | | | | | | | | | | | | * use compile_time_assert instead of DBUG_ASSERT * don't use thd->clear_error(), because * the error was already consumed by the error handler, so there is nothing to clear * it's dangerous to clear errors indiscriminately, if the error came from outside of read_statistics_for_tables() it must not be cleared
* | MDEV-20354 All but last insert ignored in InnoDB tables when table lockedSergei Golubchik2019-10-304-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mysql_insert() first opens all affected tables (which implicitly starts a transaction in InnoDB), then stat tables. A failure to open a stat table caused open_tables() to abort the current stmt transaction (trans_rollback_stmt()). So, from the server point of view the following ha_write_row()-s happened outside of a transactions, and the server didn't bother to commit them. The server has a mechanism to prevent a transaction being unexpectedly committed or rolled back in the middle of a statement - if an operation takes place _in a sub-statement_ it cannot change the transaction state. Operations on stat tables are exactly that - they are not allowed to change a transaction state. Put them in a sub-statement to make sure they don't.
* | Merge branch '10.1' into bb-10.1-releaseOleksandr Byelkin2019-10-301-1/+2
|\ \
| * | MDEV-19432 Systemd service does not get re-enabled after upgradeSergei Golubchik2019-10-301-1/+2
| | | | | | | | | | | | | | | following Fedora recommendations (see %systemd_post macro in FC29) let's do `systemctl preset` on the first installation of the server
* | | Merge branch '5.5' into 10.1Oleksandr Byelkin2019-10-303-17/+6
|\ \ \ | | |/ | |/|
| * | Revert "MDEV-14448: Ctrl-C should not exit the client"mariadb-5.5.66Sergei Golubchik2019-10-301-13/+2
| | | | | | | | | | | | This reverts commit 396313d301b3567aeadd04ae6a9322da2adc0a8b.
| * | MDEV-18783 - Server crash in hp_rb_make_keySergey Vojtovich2019-10-302-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | In debug build, whenever MEMORY table instance gets closed it performs consistency check without protection. It may cause server crash if executed concurrently with DML. Moved consistency check to ha_heap::external_lock(F_UNLCK), so that it is protected by THR_LOCK.
| * | compilation fix for Windowsbb-5.5-releaseSergei Golubchik2019-10-301-0/+2
| | |
* | | Merge remote-tracking branch 'connect/10.1' into 10.1Oleksandr Byelkin2019-10-3032-1612/+2083
|\ \ \
| * \ \ Merge branch 'ob-10.1' into 10.1Olivier Bertrand2019-08-2432-1618/+2094
| |\ \ \