- 13 May, 2020 2 commits
-
-
Monty authored
MDEV-19622 Assertion failures in ha_partition::set_auto_increment_if_higher upon UPDATE on Aria table
-
Marko Mäkelä authored
-
- 12 May, 2020 3 commits
-
-
Vlad Lesin authored
Flush LSN to system tablespace on innodb shutdown if XA is rolled back by mariabackup.
-
Marko Mäkelä authored
innobase_get_charset(), innobase_get_stmt_safe(): Remove. It is more efficient and readable to invoke thd_charset() and thd_query_safe() directly, without a non-inlined wrapper function.
-
Marko Mäkelä authored
The function thd_query_safe() is used in the implementation of the following INFORMATION_SCHEMA views: information_schema.innodb_trx information_schema.innodb_locks information_schema.innodb_lock_waits information_schema.rocksdb_trx The implementation of the InnoDB views is in trx_i_s_common_fill_table(). This function invokes trx_i_s_possibly_fetch_data_into_cache(), which will acquire lock_sys->mutex and trx_sys->mutex in order to protect the set of active transactions and explicit locks. While holding those mutexes, it will traverse the collection of InnoDB transactions. For each transaction, thd_query_safe() will be invoked. When called via trx_i_s_common_fill_table(), thd_query_safe() is acquiring THD::LOCK_thd_data while holding the InnoDB locks. This will cause a deadlock with THD::awake() (such as executing KILL QUERY), because THD::awake() could invoke lock_trx_handle_wait(), which attempts to acquire lock_sys->mutex while already holding THD::lock_thd_data. thd_query_safe(): Invoke mysql_mutex_trylock() instead of mysql_mutex_lock(). Return the empty string if the mutex cannot be acquired without waiting.
-
- 11 May, 2020 5 commits
-
-
Oleksandr Byelkin authored
-
Oleksandr Byelkin authored
-
Daniel Bartholomew authored
-
Daniel Bartholomew authored
-
Marko Mäkelä authored
As part of the SPATIAL INDEX implementation in InnoDB, dict_index_t was expanded by a rtr_ssn_t field. There are only 3 operations for this field, all protected by rtr_ssn_t::mutex: * btr_cur_search_to_nth_level() stores the least significant 32 bits of the 64-bit value that is stored in the index root page. (This would better be done when the table is opened for the very first time.) * rtr_get_new_ssn_id() increments the value by 1. * rtr_get_current_ssn_id() reads the current value. All these operations can be implemented equally safely by using atomic memory access operations.
-
- 09 May, 2020 1 commit
-
-
Petr Vaněk authored
-
- 08 May, 2020 10 commits
-
-
Jan Lindström authored
-
Sergei Golubchik authored
correct the help text
-
Oleksandr Byelkin authored
-
Oleksandr Byelkin authored
When we move data we should fix buffer string length
-
Marko Mäkelä authored
Let us limit the maximum value of the debug parameter innodb_data_file_size to 256 MiB. It is only being used in the test innodb.log_data_file_size, and the size of the system tablespace should never exceed some 70 MiB in ./mtr. Thus, 256 MiB should be a reasonable limit. The fact that negative values that are passed to unsigned parameters wrap around to the maximum value appears to be a regression due to commit 18ef02b0 and has been filed as bug MDEV-22219.
-
Sergei Golubchik authored
-
Jan Lindström authored
Enable tests with additional galera output to find out actual reason for test failures.
-
Sergei Golubchik authored
-
Sergei Golubchik authored
under LOCK TABLES we still have to open everything, otherwise DML prelocking will try to take an MDL on a table that wasn't in the LOCK TABLES list.
-
Jan Lindström authored
MDEV-21421 : Galera test sporadic failure on galera.galera_as_slave_gtid_myisam: Result length mismatch Add wait_condition so that drop table has time to replicate to Galera cluster.
-
- 07 May, 2020 2 commits
-
-
Marko Mäkelä authored
The test was incompatible with ./mtr --repeat=2 until commit 2d6719d7 fixed that. It turns out that the failing assertion that we disabled in commit 3db94d24 is bogus and can fail when the change buffer is emptied during the last batch of crash recovery. The reason for this is the condition around the page_create_empty() call in page_cur_delete_rec(). The condition was removed in MariaDB Server 10.5 as part of MDEV-12353, in commit 7ae21b18 and commit f8a9f906. The bug that the assertion aimed to catch is MDEV-22497, which was fixed in commit 26aab96e.
-
Marko Mäkelä authored
The InnoDB insert buffer was upgraded in MySQL 5.5 into a change buffer that also covers delete-mark and delete (purge) operations. There is an important constraint for delete operations: a B-tree leaf page must not become empty unless the entire tree becomes empty, consisting of an empty root page. Because change buffer merges only occur on a single leaf page at a time, delete operations must not be buffered if it is possible that the last record of the page could be deleted. (In that case, we would refuse to use the change buffer, and if we really delete the last record, we would shrink the index tree.) The function ibuf_get_volume_buffered_hash() is part of our insurance that the page would not become empty. It is supposed to map each buffered INSERT or DELETE_MARK record payload into a hash value. We will only count each such record as a distinct key if there is no hash collision. DELETE operations will always decrement the predicted number fo records in the page. Due to a bug in the function, we would actually compute the hash value not only on the record payload, but also on some following bytes, in case the record contains NULL values. In MySQL Bug #61104, we had some examples of this dating back to 2012. But back then, we failed to reproduce the bug, and in commit d84c9557 we simply demoted the hard assertion to a message printout and a debug assertion failure. ibuf_get_volume_buffered_hash(): Correctly compute the hash value of the payload bytes only. Note: we will consider ('foo','bar'),(NULL,'foobar'),('foob','ar') to be equal, but this is not a problem, because in case of a hash collision, we could also consider ('boo','far') to be equal, and underestimate the number of records in the page, leading to refusing to buffer a DELETE.
-
- 06 May, 2020 8 commits
-
-
Vladislav Vaintroub authored
-
Sergei Golubchik authored
only MDL-prelock but do not open FK child tables for read-only (RESTRICT) FK actions. Tables still needs to be opened for CASCADE actions, see 9180e866
-
Sergei Golubchik authored
-
Anel Husakovic authored
-
Jan Lindström authored
MDEV-21515 : Galera test sporadic failure on galera.galera_wsrep_new_cluster: Result content mismatch Test starts two servers and we do not know order they really start, thus wsrep_local_index can be 1 or 2.
-
Jan Lindström authored
Test seems to work.
-
Marko Mäkelä authored
We must ensure that the NUL will not terminate the query string.
-
Marko Mäkelä authored
Replace the 30-second sleep in the test with proper DEBUG_SYNC interlocking.
-
- 05 May, 2020 5 commits
-
-
Sergei Golubchik authored
MDEV-21437 MariaDB's SUSE/SLES packages don't "provide" all of the same capabilities as the platform's default packages
-
Elena Stepanova authored
-
Vladislav Vaintroub authored
-
Varun Gupta authored
Fixing a race condition while collecting the engine independent statistics. Thread1> 1) start running "ANALYZE TABLE t PERISTENT FOR COLUMNS (..) INDEXES ($list)" 2) Walk through $list and save it in TABLE::keys_in_use_for_query 3) Close/re-open tables Thread2> 1) Make some use of table t. This involves taking table t from the table cache, and putting it back (with TABLE::keys_in_use_for_query reset to 0) Thread1> continue collecting EITS stats. Since TABLE::keys_in_use_for_query is set to 0 we will not collect statistics for indexes in $list.
-
Marko Mäkelä authored
commit 6495806e removed all reads of buf_page_t::write_size. Let us remove the field altogether.
-
- 04 May, 2020 4 commits
-
-
Elena Stepanova authored
-
Marko Mäkelä authored
commit d467bb7e accidentally broke the build without WSREP, by misplacing an #endif.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
This is a partial backport of commit 5e7e7153 from 10.4. assert_trx_is_free(): Assert !is_wsrep(). trx_init(): Do not initialize trx->wsrep, because it must have been initialized already. trx_commit_in_memory(): Invoke wsrep_commit_ordered(). This call was being skipped, because the transaction object had already been freed to the pool. trx_rollback_for_mysql(), innobase_commit_low(), innobase_rollback_trx(): Always reset trx->wsrep.
-