- 02 Jul, 2020 1 commit
-
-
MikkoJaakola authored
galera_toi_truncate test launches a long term INSERT statement in node 2, and then submits an offending TRUNCATE through node 1. The idea is that the replicated TRUNCATE will conflict with INSERT in node 2, and force the INSERT to abort. The test first issues --send INSERT in node 2, and then switches to node 1 to launch --send TRUNCATE. As the INSERT is launched asynchronously by --send, it may happen that INSERT has not yet started to process, before the TRUNCATE is replicated. The net effect may be that TRUCATE processes to completion in node 2, and only after that INSERT starts to execute. As the INSERT is very long query, it will last longer than mtr test suite max test time, the test will fail for timeout. The fix in this commit uses another connection in node 2, to wait until the INSERT has started to process in node 2. TRUNCATE in node 1, will be submitted in node 1 after this wait condition.
-
- 30 Jun, 2020 3 commits
-
-
Julius Goryavsky authored
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
and remove it on error Disable existing non-empty datadir for mysql_install_db.exe
-
- 27 Jun, 2020 2 commits
-
-
Otto Kekäläinen authored
This reverts commit 9fff91b5 which was pushed on master by accident.
-
Otto Kekäläinen authored
Upstreamed from https://salsa.debian.org/mariadb-team/mariadb-10.4/-/blob/master/debian/patches/930314-cross-build.patch which has been running in Debian successfully for a year now. Original bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930314
-
- 25 Jun, 2020 1 commit
-
-
Julius Goryavsky authored
-
- 24 Jun, 2020 4 commits
-
-
Jan Lindström authored
-
Jan Lindström authored
-
sjaakola authored
When a transaction fails in certification phase, it has connsumed one GTID, but as transaction must rollback, it will not go for commit ordering, and because of this also the wsrep XID checkpointing can happen out of order. This PR will make the thread, which has failed for certiication failure to wait for its commit order turn for checkpointing wsrep IXD in innodb rollback segment. There is a specific test for wsrep XID checkpointing ordering in mtr test: mysql-wsrep-bugs-607, which is added in this PR. Test galera_slave_replay depends also on this fix, as the second test phase may also assert for bad wsrep XID checkpointing order. galera_slave_replay.test had also other problems, which caused the test to fail immediately, thse are now fixes in this PR as well.
-
Sergei Petrunia authored
- select_describe() should not attempt to produce query plans for subqueries if the query is handled by a Select Handler. - JOIN::save_explain_data_intern should not add links to Explain_select for children selects if: 1. The whole query is handled by the Select Handler, or 2. this select (and so its children) is handled by Derived Handler.
-
- 23 Jun, 2020 1 commit
-
-
Julius Goryavsky authored
-
- 22 Jun, 2020 2 commits
-
-
Jan Lindström authored
-
Eugene Kosov authored
The idea was borrowed from http://wg21.link/p0052 scope_exit class is a helper, its name is hidden from user in the namespace detail. Alternative implementation of scope_exit with std::function looks slower on goldbolt.org as it may require allocation, etc. scope_exit doesn't need to own a callable, so beeing a pointer is enough. And std::decay produces such a pointer from callable.
-
- 19 Jun, 2020 1 commit
-
-
https://github.com/codership/mariadb-serverJulius Goryavsky authored
Merge branch '10.4-MDEV-22729' of https://github.com/codership/mariadb-server into 10.4-MDEV-22729-2
-
- 18 Jun, 2020 4 commits
-
-
Varun Gupta authored
MDEV-22665: Print ranges in the optimizer trace created for non-indexed columns when optimizer_use_condition_selectivity >2 Now the optimizer trace shows the ranges constructed while getting estimates from EITS
-
Vlad Lesin authored
from configuration files
-
Vlad Lesin authored
Post-push fix: add mysqd options in backup string in mariabackup sst script for the case of logging not in syslog.
-
Marko Mäkelä authored
The test mariabackup.mdev-14447 started failing due to the option --apply-log-only that became invalid since commit 9bdf35e9 and had been removed in commit 8c71c6aa.
-
- 17 Jun, 2020 4 commits
-
-
Thirunarayanan Balathandayuthapani authored
- There is a possiblity that metadata record is the only record in the leftmost leaf page. So change the assertion to check only previous page.
-
Sergei Petrunia authored
-
Vladislav Vaintroub authored
Make sure to initialize SSL early enough, when encryption plugins is loaded
-
Krunal Bauskar authored
increased scalability through even distribution Rollback segments are allocated to transactions in round-robin fashion. This is controlled by incrementing a static-scope counter named rseg_slot. Said logic is not protected by any mutex or use of atomic for the counter. This potentially can cause the same rollback segment to get allocated to N different transactions (requesting allocation at the same time). While this is not an issue as a rollback segment can host multiple transactions from contention (performance) perspective it is better to allocate these rollback segments in round-robin fashion. Fix for the said issue ports use of atomic for the said counter that would ensure the original design semantic (even distribution through round-robin) is retained.
-
- 16 Jun, 2020 2 commits
-
-
Sachin authored
MDEV-22370 safe_mutex: Trying to lock uninitialized mutex at /data/src/10.4-bug/sql/rpl_parallel.cc, line 470 upon shutdown during FTWRL Problem:- When we issue FTWRL with shutdown in parallel, there is race between FTWRL and shutdown. Shutdown might destroy the mutex (pool->LOCK_rpl_thread_pool) before FTWRL can lock it. So we can get crash on FTWRL thread Solution:- mysql_mutex_destroy(pool->LOCK_rpl_thread_pool) should wait for FTWRL thread to complete its work , and then destroy. So slave_prepare_for_shutdown will just deactivate the pool, and mutex is destroyed later in end_slave()
-
MikkoJaakola authored
The galera.galera_parallel_autoinc_manytrx mtr test opens and runs test scenario through 3 connections to node 1 and one connection to node 2. In the test initialization phase, the test creates two tables 't1' and 'ten' and then creates a stored procedure 'p1' to operate on these tables. These 3 create DDL statements are issued through same connection to node 1. In the next test phase, the mtr script uses send command to launch the call for the p1 stored procedure through all 3 connections to node 1 and through one connection to node 2. As the mtr send command is asynchronous, this test phase is non blocking and fast operation. Now, if the replication between nodes is slow, it may happen that the initialization phase DDL statements have not been received or have not been fully applied in node 2. Therefore there is no guarantee that the test tables and the stored procedure have been created in node 2. Yet, the test is trying to call p1 in node 2. In the failure case error logs, there is error message "MTR failed: query 'reap' failed: 1305: PROCEDURE test.p1 does not exist" The reap command through connection to node 2, is the first place where test execution may observe that test tables and/or stored procedure are not yet created in node 2. The fix in this commit adds a wait condition in connection to node 2, to wait until the stored procedure is created before calling the stored procedure. The wait is implemented by looking in information_schema.routines for the p1 stored procedure.
-
- 15 Jun, 2020 1 commit
-
-
Alexey Yurchenko authored
galera_ipv6_mariabackup MTR tests
-
- 14 Jun, 2020 4 commits
-
-
Vlad Lesin authored
MDEV-21298: mariabackup doesn't read from the [mariadbd] and [mariadbd-X.Y] server option groups from configuration files MDEV-21301: mariabackup doesn't read [mariadb-backup] option group in configuration file All three issues require to change the same code, that is why their fixes are joined in one commit. The fix is in invoking load_defaults_or_exit() and handle_options() for backup-specific groups separately from client-server groups to let the last handle_options() call fail on unknown backup-specific options. The order of options procesing is the following: 1) Load server groups and process server options, ignore unknown options 2) Load client groups and process client options, ignore unknown options 3) Load backup groups and process client-server options, exit on unknown option 4) Process --mysqld-args command line options, ignore unknown options New global flag my_handle_options_init_variables was added to have ability to invoke handle_options() for the same allowed options set several times without re-initialising previously set option values. --password value destroying is moved from option processing callback to mariabackup's handle_options() function to have ability to invoke server's handle_options() several times for the same possible allowed options set. Galera invokes wsrep_sst_mariabackup.sh with mysqld command line options to configure mariabackup as close to the server as possible. It is not known what server options are supported by mariabackup when the script is invoked. That is why new mariabackup option "--mysqld-args" is added, all unknown options that follow this option will be silently ignored. wsrep_sst_mariabackup.sh was also changed to: - use "--mysqld-args" mariabackup option to pass mysqld options, - remove deprecated innobackupex mode, - remove unsupported mariabackup options: --encrypt --encrypt-key --rebuild-indexes --rebuild-threads
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
The test case that was added for MDEV-21217 (commit b68f1d84) should have only two possible outcomes for the locking SELECT statement: (1) The statement is blocked, and the test will eventually fail with a lock wait timeout. This is what I observed when the code fix for MDEV-21217 was missing. (2) The lock conflict will ensure that the statement will execute after the rollback has completed, and an empty table will be observed. This is the expected outcome with the recovery fix. What occasionally happens (in some of our CI environments only, so far) is that the locking SELECT will return all 1,000 rows of the table that had been inserted by the transaction that was never supposed to be committed. One possibility is that the transaction was unexpectedly committed when the server was killed. Let us disable the test until the reason of the failure has been determined and addressed.
-
- 13 Jun, 2020 5 commits
-
-
Sergei Golubchik authored
With RETURNING it can happen that the user has some privileges on the table (namely, DELETE), but later needs different privileges on individual columns (namely, SELECT). Do the same as in check_grant_column() - ER_COLUMNACCESS_DENIED_ERROR, not an assert.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
trx_roll_must_shutdown(): Correct the condition that detects the start of shutdown.
-
Alexander Barkov authored
Item_func_div::fix_length_and_dec_temporal() set the return data type to integer in case of @div_precision_increment==0 for temporal input with FSP=0. This caused Item_func_div to call int_op(), which is not implemented, so a crash on DBUG_ASSERT(0) happened. Fixing fix_length_and_dec_temporal() to set the result type to DECIMAL.
-
- 12 Jun, 2020 2 commits
-
-
Vicențiu Ciorbaru authored
-
Alexander Barkov authored
MDEV-22499 Assertion `(uint) (table_check_constraints - share->check_constraints) == (uint) (share->table_check_constraints - share->field_check_constraints)' failed in TABLE_SHARE::init_from_binary_frm_image The patch for MDEV-22111 fixed MDEV-22499 as well. Adding tests only.
-
- 11 Jun, 2020 3 commits
-
-
Vicențiu Ciorbaru authored
-
Alexander Barkov authored
Item_cache_datetime::decimals was always copied from example->decimals without limiting to 6 (maximum possible fractional digits), so val_str() later crashed on asserts inside my_time_to_str() and my_datetime_to_str().
-
Alexander Barkov authored
MDEV-22755 CREATE USER leads to indirect SIGABRT in __stack_chk_fail () from fill_schema_user_privileges + *** stack smashing detected *** (on optimized builds) The code erroneously used buff[100] in a fiew places to make a GRANTEE value in the form: 'user'@'host' Fix: - Fixing the code to use (USER_HOST_BUFF_SIZE + 6) instead of 100. - Adding a DBUG_ASSERT to make sure the buffer is enough - Wrapping the code into a class Grantee_str, to reuse it easier in 4 places.
-