- 16 Jan, 2017 3 commits
-
-
Marko Mäkelä authored
The function fsp_flags_try_adjust(), which is called on startup, is incrementing the Innodb_pages0_read counts for every affected file. Adjust the result of encryption.innodb_lotoftables accordingly.
-
Marko Mäkelä authored
innodb.doublewrite: Similar to what was done to innodb.101_compatibility, add an explicit $_ parameter to the Perl unpack function. Also, fix some diagnostic messages in the Perl code. innodb.innodb-wl5522-debug: Adjust for the changed error codes and messages on fault injection.
-
Elena Stepanova authored
Apparently, in older versions of Perl unpack does not have a logic for using $_ as a default value for the second argument. Fixed by specifying it explicitly
-
- 15 Jan, 2017 8 commits
-
-
Elena Stepanova authored
-
Marko Mäkelä authored
MariaDB 10.0/MySQL 5.6 using innodb-page-size!=16K The storage format of FSP_SPACE_FLAGS was accidentally broken already in MariaDB 10.1.0. This fix is bringing the format in line with other MySQL and MariaDB release series. Please refer to the comments that were added to fsp0fsp.h for details. This is an INCOMPATIBLE CHANGE that affects users of page_compression and non-default innodb_page_size. Upgrading to this release will correct the flags in the data files. If you want to downgrade to earlier MariaDB 10.1.x, please refer to the test innodb.101_compatibility how to reset the FSP_SPACE_FLAGS in the files. NOTE: MariaDB 10.1.0 to 10.1.20 can misinterpret uncompressed data files with innodb_page_size=4k or 64k as compressed innodb_page_size=16k files, and then probably fail when trying to access the pages. See the comments in the function fsp_flags_convert_from_101() for detailed analysis. Move PAGE_COMPRESSION to FSP_SPACE_FLAGS bit position 16. In this way, compressed innodb_page_size=16k tablespaces will not be mistaken for uncompressed ones by MariaDB 10.1.0 to 10.1.20. Derive PAGE_COMPRESSION_LEVEL, ATOMIC_WRITES and DATA_DIR from the dict_table_t::flags when the table is available, in fil_space_for_table_exists_in_mem() or fil_open_single_table_tablespace(). During crash recovery, fil_load_single_table_tablespace() will use innodb_compression_level for the PAGE_COMPRESSION_LEVEL. FSP_FLAGS_MEM_MASK: A bitmap of the memory-only fil_space_t::flags that are not to be written to FSP_SPACE_FLAGS. Currently, these will include PAGE_COMPRESSION_LEVEL, ATOMIC_WRITES and DATA_DIR. Introduce the macro FSP_FLAGS_PAGE_SSIZE(). We only support one innodb_page_size for the whole instance. When creating a dummy tablespace for the redo log, use fil_space_t::flags=0. The flags are never written to the redo log files. Remove many FSP_FLAGS_SET_ macros. dict_tf_verify_flags(): Remove. This is basically only duplicating the logic of dict_tf_to_fsp_flags(), used in a debug assertion. fil_space_t::mark: Remove. This flag was not used for anything. fil_space_for_table_exists_in_mem(): Remove the unnecessary parameter mark_space, and add a parameter for table flags. Check that fil_space_t::flags match the table flags, and adjust the (memory-only) flags based on the table flags. fil_node_open_file(): Remove some redundant or unreachable conditions, do not use stderr for output, and avoid unnecessary server aborts. fil_user_tablespace_restore_page(): Convert the flags, so that the correct page_size will be used when restoring a page from the doublewrite buffer. fil_space_get_page_compressed(), fsp_flags_is_page_compressed(): Remove. It suffices to have fil_space_is_page_compressed(). FSP_FLAGS_WIDTH_DATA_DIR, FSP_FLAGS_WIDTH_PAGE_COMPRESSION_LEVEL, FSP_FLAGS_WIDTH_ATOMIC_WRITES: Remove, because these flags do not exist in the FSP_SPACE_FLAGS but only in memory. fsp_flags_try_adjust(): New function, to adjust the FSP_SPACE_FLAGS in page 0. Called by fil_open_single_table_tablespace(), fil_space_for_table_exists_in_mem(), innobase_start_or_create_for_mysql() except if --innodb-read-only is active. fsp_flags_is_valid(ulint): Reimplement from the scratch, with accurate comments. Do not display any details of detected inconsistencies, because the output could be confusing when dealing with MariaDB 10.1.x data files. fsp_flags_convert_from_101(ulint): Convert flags from buggy MariaDB 10.1.x format, or return ULINT_UNDEFINED if the flags cannot be in MariaDB 10.1.x format. fsp_flags_match(): Check the flags when probing files. Implemented based on fsp_flags_is_valid() and fsp_flags_convert_from_101(). dict_check_tablespaces_and_store_max_id(): Do not access the page after committing the mini-transaction. IMPORT TABLESPACE fixes: AbstractCallback::init(): Convert the flags. FetchIndexRootPages::operator(): Check that the tablespace flags match the table flags. Do not attempt to convert tablespace flags to table flags, because the conversion would necessarily be lossy. PageConverter::update_header(): Write back the correct flags. This takes care of the flags in IMPORT TABLESPACE.
-
Marko Mäkelä authored
contains a bad and a good copy Clean up the InnoDB doublewrite buffer code. buf_dblwr_init_or_load_pages(): Do not add empty pages to the buffer. buf_dblwr_process(): Do consider changes to pages that are all zero. Do not abort when finding a corrupted copy of a page in the doublewrite buffer, because there could be multiple copies in the doublewrite buffer, and only one of them needs to be good.
-
Marko Mäkelä authored
-
Sergei Golubchik authored
sometimes table->s->stored_fields is less than table->s->null_fields
-
Sergei Golubchik authored
-
Sergei Golubchik authored
safe_mutex: Found wrong usage of mutex 'LOCK_thread_count' and 'LOCK_status' Mutex currently locked (in reverse order): LOCK_status sql/sql_class.h line 3873 LOCK_thread_count libmysqld/lib_sql.cc line 432
-
Sergei Golubchik authored
-
- 12 Jan, 2017 2 commits
-
-
Alexander Barkov authored
Fixing Item::decimal_precision() to return at least one digit. This fixes the problem reported in MDEV. Also, fixing Item_func_signed::fix_length_and_dec() to reserve space for at least one digit (plus one character for an optional sign). This is needed to have CONVERT(expr,SIGNED) and CONVERT(expr,UNSIGNED) create correct string fields when they appear in string context, e.g.: CREATE TABLE t1 AS SELECT CONCAT(CONVERT('',SIGNED));
-
Marko Mäkelä authored
Test crash recovery from an encrypted redo log with innodb_encrypt_log=0. Previously, we did a clean shutdown, so only the log checkpoint information would have been read from the redo log. With this change, we will be reading and applying encrypted redo log records. include/start_mysqld.inc: Observe $restart_parameters. encryption.innodb-log-encrypt: Remove some unnecessary statements, and instead of restarting the server and concurrently accessing the files while the server is running, kill the server, check the files, and finally start up the server. innodb.log_data_file_size: Use start_mysqld.inc with $restart_parameters.
-
- 11 Jan, 2017 4 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
The symbol HAVE_VALGRIND_MEMCHECK_H was never defined. Instead, the symbol HAVE_VALGRIND should have been used.
-
Elena Stepanova authored
-
- 10 Jan, 2017 2 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
buf_flush_init_flush_rbt() was called too early in MariaDB server 10.0, 10.1, MySQL 5.5 and MySQL 5.6. The memory leak has been fixed in the XtraDB storage engine and in MySQL 5.7. As a result, when the server is started to initialize new data files, the buf_pool->flush_rbt will be created unnecessarily and then leaked. This memory leak was noticed in MariaDB server 10.1 when running the test encryption.innodb_first_page.
-
- 09 Jan, 2017 3 commits
-
-
Alexey Botchkov authored
Have to use 'keyname' to check the name uniqueness.
-
Marko Mäkelä authored
Perform a slow shutdown at the start of the test, and create all InnoDB tables with STATS_PERSISTENT=0, so that any I/O related to background tasks (change buffer merge, purge, persistent statistics) should be eliminated.
-
Marko Mäkelä authored
This should be a non-functional change. I was unable to repeat MDEV-11626 innodb.innodb-change-buffer-recovery fails for xtradb and cannot determine the reason for the failure without having access to the files. The repeatability of MDEV-11626 should not be affected by these changes.
-
- 08 Jan, 2017 1 commit
-
-
Monty authored
MDEV-11317: `! is_set()' or `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' fails in Diagnostics_area::set_ok_status on CREATE OR REPLACE with ARCHIVE table Problem was with deleting non existing .frm file for a storage engine that doesn't have .frm files (yet) Fixed by not giving an error for non existing .frm files for storage engines that are using discovery Fixed also valgrind supression related to the given test case
-
- 07 Jan, 2017 1 commit
-
-
Marko Mäkelä authored
Sometimes innodb_data_file_size_debug was reported as INT UNSIGNED instead of BIGINT UNSIGNED. Make it uint instead of ulong to get a more deterministic result.
-
- 06 Jan, 2017 5 commits
-
-
Vladislav Vaintroub authored
Add <install_root>/data/my.ini to the search path - this my.ini location is used since MariaDB 5.2
-
Vladislav Vaintroub authored
for the default installation. It is now defined as "C:/Program Files/MariaDB ${MYSQL_BASE_VERSION}" which is where installer indeed puts it by default. It still does not cover every case -32bit installer on 64 bit Windows would put installation root under "C:/Program Files (x86)", but better than the path used previously C:/MariaDB${MYSQL_BASE_VERSION}, which was never correct.
-
Vladislav Vaintroub authored
in default installation. Added plugin-dir to the [client] section of the generated my.ini, so that installed services (MSI or mysql_install_db.exe) would be able to find plugin directory.
-
Dmitry Lenev authored
MDEV-9084 Calling a stored function from a nested select from temporary table causes unpredictable behavior Cherry-pick: f4a0af070ce49abae60040f6f32e1074309c27fb Author: Dmitry Lenev <dmitry.lenev@oracle.com> Date: Mon Jul 25 16:06:52 2016 +0300 Fix for bug #16672723 "CAN'T FIND TEMPORARY TABLE". Attempt to execute prepared CREATE TABLE SELECT statement which used temporary table in the subquery in FROM clause and stored function failed with unwarranted ER_NO_SUCH_TABLE error. The same happened when such statement was used in stored procedure and this procedure was re-executed. The problem occurred because execution of such prepared statement/its re-execution as part of stored procedure incorrectly set Query_table_list::query_tables_own_last marker, indicating the last table which is directly used by statement. As result temporary table used in the subquery was treated as indirectly used/belonging to prelocking list and was not pre-opened by open_temporary_tables() call before statement execution. Thus causing ER_NO_SUCH_TABLE errors since our code assumes that temporary tables need to be correctly pre-opened before statement execution. This problem became visible only in version 5.6 after patches related to bug 11746602/27480 "EXTEND CREATE TEMPORARY TABLES PRIVILEGE TO ALLOW TEMP TABLE OPERATIONS" since they have introduced pre-opening of temporary tables for statements. Incorrect setting of Query_table_list::query_tables_own_last happened in LEX::first_lists_tables_same() method which is called by CREATE TABLE SELECT implementation as part of LEX::unlink_first_table(), which temporary excludes table list element for table being created from the query table list before handling SELECT part. LEX::first_lists_tables_same() tries to ensure that global table list of the statement starts with the first table list element from the first statement select. To do this it moves such table list element to the head of the global table list. If this table happens to be last directly-used table for the statement, query_tables_own_last marker is pointing to it. Since this marker was not updated when table list element was moved we ended up with all tables except the first table separated by it as if they were not directly used by statement (i.e. belonged to prelocked tables list). This fix changes code of LEX::first_lists_tables_same() to update query_tables_own_last marker in cases when it points to the table being moved. It is set to the table which precedes table being moved in this case.
-
Kristian Nielsen authored
Make the slave SQL thread always output to the error log the message "Slave SQL thread exiting, replication stopped in ..." whenever it previously outputted "Slave SQL thread initialized, starting replication ...". Before this patch, it was somewhat inconsistent in which cases the message would be output and in which not, depending on the exact time and cause of the condition that caused the SQL thread to stop.
-
- 05 Jan, 2017 6 commits
-
-
Elena Stepanova authored
MTR raises default wait_for_pos_timeout from 300 to 1500 when tests are run with valgrind. The same needs to be done for other replication-related waits. The change should fix one of failures mentioned in MDEV-10653 (rpl.rpl_parallel fails in buildbot with timeout), the one on the valgrind builder; but not all of them
-
Elena Stepanova authored
Add diagnostics output if any Sphinx components aren't found
-
Marko Mäkelä authored
-
Marko Mäkelä authored
Memory was leaked when ALTER TABLE is attempted on a table that contains corrupted indexes. The memory leak was reported by AddressSanitizer for the test innodb.innodb_corrupt_bit. The leak was introduced into MariaDB Server 10.0.26, 10.1.15, 10.2.1 by the following: commit c081c978 Merge: 1d21b221 a482e76e Author: Sergei Golubchik <serg@mariadb.org> Date: Tue Jun 21 14:11:02 2016 +0200 Merge branch '5.5' into bb-10.0
-
Marko Mäkelä authored
-
Marko Mäkelä authored
In the backport of Bug#24450908 UNDO LOG EXISTS AFTER SLOW SHUTDOWN from MySQL 5.7 to the MySQL 5.6 based MariaDB Server 10.1, we must use a mutex when HAVE_ATOMIC_BUILTINS is not defined. Also, correct a function comment. In MySQL 5.6 and MariaDB Server 10.1, also temporary InnoDB tables are redo-logged.
-
- 04 Jan, 2017 5 commits
-
-
Marko Mäkelä authored
encryption.innodb_scrub: Clean up. Make it also cover ROW_FORMAT=COMPRESSED, removing the need for encryption.innodb_scrub_compressed. Add a FIXME comment saying that we should create a secondary index, to demonstrate that also undo log pages get scrubbed. Currently that is not working! Also clean up encryption.innodb_scrub_background, but keep it disabled, because the background scrubbing does not work reliably. Fix both tests so that if something is not scrubbed, the test will be aborted, so that the data files will be preserved. Allow the tests to run on Windows as well.
-
Marko Mäkelä authored
InnoDB shutdown failed to properly take fil_crypt_thread() into account. The encryption threads were signalled to shut down together with other non-critical tasks. This could be much too early in case of slow shutdown, which could need minutes to complete the purge. Furthermore, InnoDB failed to wait for the fil_crypt_thread() to actually exit before proceeding to the final steps of shutdown, causing the race conditions. Furthermore, the log_scrub_thread() was shut down way too early. Also it should remain until the SRV_SHUTDOWN_FLUSH_PHASE. fil_crypt_threads_end(): Remove. This would cause the threads to be terminated way too early. srv_buf_dump_thread_active, srv_dict_stats_thread_active, lock_sys->timeout_thread_active, log_scrub_thread_active, srv_monitor_active, srv_error_monitor_active: Remove a race condition between startup and shutdown, by setting these in the startup thread that creates threads, not in each created thread. In this way, once the flag is cleared, it will remain cleared during shutdown. srv_n_fil_crypt_threads_started, fil_crypt_threads_event: Declare in global rather than static scope. log_scrub_event, srv_log_scrub_thread_active, log_scrub_thread(): Declare in static rather than global scope. Let these be created by log_init() and freed by log_shutdown(). rotate_thread_t::should_shutdown(): Do not shut down before the SRV_SHUTDOWN_FLUSH_PHASE. srv_any_background_threads_are_active(): Remove. These checks now exist in logs_empty_and_mark_files_at_shutdown(). logs_empty_and_mark_files_at_shutdown(): Shut down the threads in the proper order. Keep fil_crypt_thread() and log_scrub_thread() alive until SRV_SHUTDOWN_FLUSH_PHASE, and check that they actually terminate.
-
Marko Mäkelä authored
Port a bug fix from MySQL 5.7, so that all undo log pages will be freed during a slow shutdown. We cannot scrub pages that are left allocated. commit 173e171c6fb55f064eea278c76fbb28e2b1c757b Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com> Date: Fri Sep 9 18:01:27 2016 +0530 Bug #24450908 UNDO LOG EXISTS AFTER SLOW SHUTDOWN Problem: ======== 1) cached undo segment is not removed from rollback segment history (RSEG_HISTORY) during slow shutdown. In other words, If the segment is not completely free, we are failing to remove an entry from the history list. While starting the server, we traverse all rollback segment slots history list and make it as list of undo logs to be purged in purge queue. In that case, purge queue will never be empty after slow shutdown. 2) Freeing of undo log segment is linked with removing undo log header from history. Fix: ==== 1) Have separate logic of removing the undo log header from history list from rollback segment slots and remove it from rollback segment history even though it is not completely free. Reviewed-by: Debarun Banerjee <debarun.banerjee@oracle.com> Reviewed-by: Marko Mäkelä <marko.makela@oracle.com> RB:13672
-
Elena Stepanova authored
- fix the test to avoid false-negatives before MDEV-5114 patch; - fix the race condition which made the test fail on slow builders
-
Oleksandr Byelkin authored
Ability to print lock type added. Restoring correct lock type for CREATE VIEW added.
-