- 07 Mar, 2022 1 commit
-
-
Daniel Black authored
During an increase in resize, the new curr_size got a value less than old_size. As n_chunks_new and n_chunks have a strong correlation to the resizing operation in progress, we can use them and remove the need for old_size. For convienece the n_chunks_new < n_chunks is now the is_shrinking function. The volatile compiler optimization on n_chunks{,_new} is removed as real mutex uses are needed. Other n_chunks_new/n_chunks methods: n_chunks_new and n_chunks almost always read and altered under the pool mutex. Exceptions are: * i_s_innodb_buffer_page_fill, * buf_pool_t::is_uncompressed (via is_blocked_field) These need reexamining for the need of a mutex, however comments indicates this already. get_n_pages has uses in buffer pool load, recover log memory exhaustion estimates and innodb status so take the minimum number of chunks for safety. The buf_pool_t::running_out function also uses curr_size/old_size. We replace this hot function calculation with just n_chunks_new. This is the new size of the chunks before the resizing occurs. If we are resizing down, we've already got the case we had previously (as the minimum). If we are resizing upwards, we are taking an optimistic view that there will be buffer chunks available for locks. As this memory allocation is occurring immediately next the resizing function it seems likely. Compiler hint UNIV_UNLIKELY removed to leave it to the branch predictor to make an informed decision. Added test case of a smaller size than the Marko/Roel original in JIRA reducing the size to 256M. SEGV hits roughly 1/10 times but its better than a 21G memory size. Reviewer: Marko
-
- 03 Mar, 2022 1 commit
-
-
Otto Kekäläinen authored
Among others: existance -> existence reinitialze -> reinitialize successfuly -> successfully
-
- 01 Mar, 2022 7 commits
-
-
Marko Mäkelä authored
create_table_info_t::innobase_table_flags(): Ignore page_compressed and page_compression_level on TEMPORARY tables. ha_innobase::truncate(): Add a debug assertion that create() must succeed on temporary tables.
-
Marko Mäkelä authored
-
Sergei Petrunia authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
The test innodb.log_file_size would occasionally crash in a debug assertion failure in srv_prepare_to_delete_redo_log_file(). In the core dump, the assertion would hold. buf_pool_t::any_io_pending(): Avoid dirty reads by acquiring buf_pool.mutex. This function is only being invoked in debug builds, so we do not care about any performance impact.
-
Marko Mäkelä authored
Already the detection part of have_crypt.inc must be skipped in WITH_MSAN builds until the SIGSEGV in the crypt() interceptor has been fixed.
-
- 28 Feb, 2022 10 commits
-
-
Monty authored
The follwoing could happen if InnoDB did some background work while test was running: @@ -5,6 +5,8 @@ SELECT LOCK_MODE, LOCK_TYPE, TABLE_SCHEMA, TABLE_NAME FROM information_schema.metadata_lock_info; LOCK_MODE LOCK_TYPE TABLE_SCHEMA TABLE_NAME MDL_SHARED_HIGH_PRIO Table metadata lock test t1 +MDL_SHARED Table metadata lock mysql innodb_table_stats +MDL_SHARED Table metadata lock mysql innodb_index_stat
-
Marko Mäkelä authored
-
Marko Mäkelä authored
We will move all tests of the ENCRYPT() function to the test main.func_crypt, which will be disabled in MSAN builds for now.
-
Marko Mäkelä authored
In merge cc1d9062 the 32-bit builds were broken.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
In commit c7d04487 (MDEV-15132) MariaDB Server 10.3 stopped writing the latest transaction identifier to the TRX_SYS page. Instead, the transaction identifier will be recovered from undo log pages. Unfortunately, before commit 3926673c and mysql/mysql-server@dc29792ff2996aefbb6e64bb2f0bc3aa8fc879e9 (MySQL 5.1.48 or MariaDB 5.1.48) InnoDB did not always initialize all data fields, but some garbage could be left behind in unused parts of data pages. In undo log pages that are essentially free, but added to a list for reuse (TRX_UNDO_CACHED) the TRX_UNDO_TRX_NO fields could contain garbage, instead of 0. As long as such undo pages are being reused and never marked completely free, the garbage contents may remain forever. In fact, the function trx_undo_header_create() and the record MLOG_UNDO_HDR_CREATE will only initialize TRX_UNDO_TRX_ID, but leave TRX_UNDO_TRX_NO uninitialized. trx_undo_mem_create_at_db_start(): Only read the TRX_UNDO_TRX_NO fields of TRX_UNDO_CACHED pages if the TRX_UNDO_PAGE_TYPE is 0, that is, the page was updated by MariaDB Server 10.3. Earlier versions would always write the TRX_UNDO_PAGE_TYPE as 1 or 2. trx_undo_header_create(): Zero out the TRX_UNDO_TRX_NO field. Strictly speaking, this will change the semantics of the MLOG_UNDO_HDR_CREATE record, but it should not do any harm to overwrite a potentially garbage field with zeroes. Note: This fix will only help future upgrades straight from MariaDB Server 10.2 or MySQL 5.6 or earlier. If such an upgrade has already been made, then an earlier server startup could have fast-forwarded the transaction ID sequence to a large value. If this large value cannot be represented in 48 bits (the size of the DB_TRX_ID column in clustered index records), then various strange things can happen.
-
Marko Mäkelä authored
-
- 25 Feb, 2022 12 commits
-
-
Brandon Nesterenko authored
DEBUG_SYNC signals can get lost in certain tests due to later DEBUG_SYNC commands overwriting them. This patch addresses these issues in three tests: main.query_cache_debug, main.partition_debug_sync, and rpl.rpl_dump_request_retry_warning. Additionally, main.partition_debug_sync needed changes to the result file (the others did not). The synchronization happened between two commands, one based on ALTER, the other on DROP. A new thread/connection was needed to synchronize the DEBUG_SYNC actions between these commands, thereby changing the result file. Additional comments were added for clarification. Reviewed By: ============ Andrei Elkin <andrei.elkin@mariadb.com>
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
- 24 Feb, 2022 4 commits
-
-
Thirunarayanan Balathandayuthapani authored
- Make innodb_ft_cache_size & innodb_ft_total_cache_size are dynamic variable and increase the maximum value of innodb_ft_cache_size to 512MB for 32-bit system and 1 TB for 64-bit system and set innodb_ft_total_cache_size maximum value to 1 TB for 64-bit system. - Print warning if the fts cache exceeds the innodb_ft_cache_size and also unlock the cache if fts cache memory reduces less than innodb_ft_cache_size.
-
Krunal Bauskar authored
- In 10.6, trx_rseg_t mutex was ported to use latch. As part of this porting profiling of the patch was removed. This patch reenables it given that the said latch continues to occupy the top-slots in the contention list.
-
Like Ma authored
-
Daniel Black authored
Order by results in MTR test to make it predictable.
-
- 23 Feb, 2022 5 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
Disable some tests that are too slow or big for MSAN.
-
Marko Mäkelä authored
-
Julius Goryavsky authored
This commit adds validation of the values of the ssl-mode parameter in SSL scripts, since now only a basic check for the presence of the "VERIFY_" prefix is performed there to detect "VERIFY_IDENTITY" and "VERIFY_CA", but all other values are not checked at all. In addition, this commit removes leading and trailing spaces from parameter values that SST scripts read from configuration files or from the command line so that they do not interfere with parameter checks and substitutions. Parameter substitution has been made more robust against characters in strings that the shell might erroneously interpret as regexp.
-
Marko Mäkelä authored
When recovery is rolling back an incomplete instant DROP COLUMN operation, it may access non-existing fields. Let us avoid invoking std::find_if() outside the valid bounds of the array. This bug was reproduced with the Random Query Generator, using a combination of instant DROP, ADD...FIRST, CHANGE (renaming a column). Unfortunately, we were unable to create an mtr test case for reproducing this, despite spending considerable effort on it.
-