summaryrefslogtreecommitdiff
path: root/mysql-test/suite/sys_vars
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-22711 Assertion `nr != 0' failed in handler::update_auto_increment.bb-10.2-mdev-22711-hfAlexey Botchkov2021-10-262-0/+45
| | | | | DBUG_ASSERT removed as the AUTO INCREMENT can actually be 0 when the SET insert_id= 0; was done.
* revive innodb_debug_syncNikita Malyavin2021-04-271-0/+12
| | | | | | | | | | | | | innodb_debug_sync was introduced in commit b393e2cb0c079b30563dcc87a62002c9c778643c and reverted in commit fc58c1721631fcc6c9414482b3b7e90cd8e7325d due to memory leak reported by valgrind, see MDEV-21336. The leak is now fixed by adding `rw_lock_free(&slot->debug_sync_lock)` after background thread working loop is finished, and the patch is reapplied, with respect to c++98 fixes by Marko. The missing DEBUG_SYNC for MDEV-18546 in row0vers.cc is also reapplied.
* MDEV-23076 Misleading "InnoDB: using atomic writes"Marko Mäkelä2021-03-221-1/+1
| | | | | | | | | | | | | | | | | | As suggested by Vladislav Vaintroub, let us remove misleading and malformatted startup messages. Even if the global variable srv_use_atomic_writes were set, we would still invoke my_test_if_atomic_write() to check if writes are atomic with a particular page size. When using the default innodb_page_size=16k, page writes should be atomic on NTFS when using ROW_FORMAT=COMPRESSED and KEY_BLOCK_SIZE<=4. Disabling srv_use_atomic_writes when innodb_file_per_table=OFF does not make sense, because that is a dynamic parameter. We also correct the documentation string of innodb_use_atomic_writes and remove the duplicate variable innobase_use_atomic_writes.
* MDEV-22653: Remove the useless parameter innodb_simulate_comp_failuresMarko Mäkelä2021-03-223-154/+0
| | | | | | | | | The debug parameter innodb_simulate_comp_failures injected compression failures for ROW_FORMAT=COMPRESSED tables, breaking the pre-existing logic that I had implemented in the InnoDB Plugin for MySQL 5.1 to prevent compressed page overflows. A much better check is already achieved by defining UNIV_ZIP_COPY at the compilation time. (Only UNIV_ZIP_DEBUG is part of cmake -DWITH_INNODB_EXTRA_DEBUG=ON.)
* make @@wsrep_provider and @@wsrep_notify_cmd read-onlymariadb-10.2.37Sergei Golubchik2021-02-187-271/+2
| | | | this should simplify run-time cluster management
* MDEV-24536 innodb_idle_flush_pct has no effectMarko Mäkelä2021-01-133-2/+14
| | | | | | | | | The parameter innodb_idle_flush_pct that was introduced in MariaDB Server 10.1.2 by MDEV-6932 has no effect ever since the InnoDB changes from MySQL 5.7.9 were applied in commit 2e814d4702d71a04388386a9f591d14a35980bfe. Let us declare the parameter as deprecated and having no effect.
* MDEV-4677 GROUP_CONCAT not showing any output with group_concat_max_len >= 4GbSergei Golubchik2020-12-102-4/+4
| | | | | don't allow group_concat_max_len values >= 4Gb (they never worked anyway)
* MDEV-24033: SIGSEGV in __memcmp_avx2_movbe from queue_insert | SIGSEGV in ↵Sergei Golubchik2020-12-106-757/+270
| | | | | | __memcmp_avx2_movbe from native_compare don't allow too small max_sort_length values
* Merge branch '10.1' into 10.2Oleksandr Byelkin2020-10-291-8/+8
|\
| * MDEV-23702 calculating(auto rounding) issueSergei Golubchik2020-10-291-8/+8
| | | | | | | | | | | | | | | | | | | | Implement a different fix for "MDEV-19232: Floating point precision / value comparison problem" Instead of truncating decimal values after every division, truncate them for comparison purposes. This reverts commit 62d73df6b270 but keeps the test.
* | Merge branch '10.1' into 10.2Oleksandr Byelkin2020-10-284-26/+29
|\ \ | |/
| * MDEV-20744 SET GLOBAL `replicate_do_db` = DEFAULT causes crash.bb-10.1-hfAlexey Botchkov2020-10-232-0/+7
| | | | | | | | DEFAULT for the replicate_do_db is the "" as our documentation states.
| * MDEV-10149: sys_vars.rpl_init_slave_func fails sporadically in buildbotSujatha2020-10-222-27/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | problem: ======== mysqltest: In included file "./include/assert.inc": included from mysql-test/suite/sys_vars/t/rpl_init_slave_func.test at line 69: Assertion text: '@@global.max_connections = @start_max_connections' Assertion result: '0' mysqltest: In included file "./include/assert.inc": included from mysql-test/suite/sys_vars/t/rpl_init_slave_func.test at line 86: Assertion text: '@@global.max_connections = @start_max_connections + 1' Assertion result: '0' Analysis: ========= A slave SQL thread sets its Running state to Yes very early in its initialisation, before the majority of initialisation actions, including executing the init_slave command, are done. Thus the testcase has a race condition where the initial replication setup might finish executing later than the testcase SET GLOBAL init_slave, making the testcase see its effect where it checks for its absence. Fix: === Include 'sync_slave_sql_with_master.inc' at the beginning of the test to ensure that slave applier has completed the execution of 'init_slave' command and proceeded to event application. Replace the apparently needless RESET MASTER / RESET SLAVE etc. Patch is based on: https://github.com/percona/percona-server/pull/1464/commits/b91e2e6f90611aa299c302929fb8b068e8ac0dee Author: laurynas-biveinis
* | MDEV-16952 Introduce SET GLOBAL innodb_max_purge_lag_waitMarko Mäkelä2020-10-271-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let us introduce a dummy variable innodb_max_purge_lag_wait for waiting that the InnoDB history list length is below the user-specified limit. Specifically, SET GLOBAL innodb_max_purge_lag_wait=0; should wait for all history to be purged. This could be useful when upgrading from an older version to MariaDB 10.3 or later, to avoid hitting MDEV-15912. Note: the history cannot be purged if there exist transactions that may see old versions. Reviewed by: Vladislav Vaintroub
* | MDEV-22524 SIGABRT in safe_mutex_unlock withAlexey Botchkov2020-10-272-0/+4
| | | | | | | | | | | | | | session_track_system_variables and max_relay_log_size. lock LOCK_global_system_variables around the get_one_variable() call in the Session_sysvars_tracker::store_variable().
* | MDEV-23720 Change innodb_log_optimize_ddl=OFF by defaultMarko Mäkelä2020-10-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MariaDB 10.2.2 inherited from MySQL 5.7 a perceived optimization of ALTER TABLE, which skips the writing of redo log records. In MDEV-16809 we introduced a parameter that allows the redo log to be written, so that Mariabackup would not be impacted, but we kept the MySQL 5.7 behaviour enabled by default (innodb_log_optimize_ddl=ON). As noted in MDEV-19747 (Deprecate and ignore innodb_log_optimize_ddl, implemented in MariaDB 10.5.1), omitting the redo log writes can actually reduce performance, because we will have to wait for the data pages to be written out. When the redo log file is configured to be large enough, it actually can be much faster to write the redo log and avoid the extra page flushing. When the redo log is omitted (innodb_log_optimize_ddl=ON), also Mariabackup may have to perform a lot of extra work, to re-copy the entire data file if it is possible that any log was omitted during the backup. Starting with MariaDB 10.5.1, the parameter innodb_log_optimize_ddl is deprecated and ignored. We hereby deprecate (but will not ignore) the parameter in earlier versions as well.
* | MDEV-23492 performance_schema_digests_size changing from default to 5000 ↵Sergei Golubchik2020-10-232-2/+2
| | | | | | | | | | | | when enabling performance_schema max allowed value limit should be larger than any auto-sized value
* | Merge 10.1 into 10.2Marko Mäkelä2020-10-212-2/+2
|\ \ | |/
| * InnoDB 5.6.50Marko Mäkelä2020-10-213-3/+3
| | | | | | | | | | The only applicable InnoDB change to MariaDB that was made between MySQL 5.6.49 and MySQL 5.6.50 is MDEV-23999.
| * Revert "[MDEV-7978] add show create user"Daniel Black2020-09-242-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Appoligies, had a dirty branch before pushing: This reverts commit 053653a23cac6f3f2e5288979438de27c9d0100a. This reverts commit 0ff897807fc2f4a32e1ba1ae148005930ea604b5. This reverts commit 85b085972b729f6c049050f851692c9a5b86f3d5. This reverts commit f3f45e46b614bddcef0a37f4352c5909ca565d1d. This reverts commit a470b3570a7ce2534c9021f3b84d7457a3ba08e1. This reverts commit f8b8d202bc83d3de46c89ef86333fe602e711265. This reverts commit 6b6f066fdd9f5f64813ded550e7dbda176ee3c82. This reverts commit a701e9e6c390c3cbac69872e95b1aec565341d30. This reverts commit c169838611e13c9f0559b2f49ba8c36aec11a78b.
| * [MDEV-7978] Update test cases for sysvars_server_embedded.Vicențiu Ciorbaru2020-09-201-2/+2
| |
| * [MDEV-7978] Update test casesVicențiu Ciorbaru2020-09-201-2/+2
| | | | | | | | Update test to account for the new SHOW CREATE USER command.
| * [MDEV-7978] Update test casesVicențiu Ciorbaru2020-09-201-2/+2
| | | | | | | | Adding an extra statement requires test cases update.
* | Remove unnecessary and incorrect add_suppression.Jan Lindström2020-10-052-3/+0
| | | | | | | | | | | | Changes to be committed: modified: mysql-test/suite/sys_vars/r/wsrep_cluster_address_basic.result modified: mysql-test/suite/sys_vars/t/wsrep_cluster_address_basic.test
* | MDEV-16664: Add deprecation warning for innodb_lock_schedule_algorithm=VATSMarko Mäkelä2020-10-051-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The setting innodb_lock_schedule_algorithm=VATS that was introduced in MDEV-11039 (commit 021212b525e39d332cddd0b9f1656e2fa8044905) causes conflicting exclusive locks to be incorrectly granted to two transactions. Specifically, in lock_rec_insert_by_trx_age() the predicate !lock_rec_has_to_wait_in_queue(in_lock) would hold even though an active transaction is already holding an exclusive lock. This was observed between two DELETE of the same clustered index record. The HASH_DELETE invocation in lock_rec_enqueue_waiting() may be related. Due to lack of progress in diagnosing the problem, we will deprecate the option and issue a warning that using it may corrupt data. The unsafe option was enabled between commit 0c15d1a6ff0d18da946f050cfeac176387a76112 (MariaDB 10.2.3) and the parent of commit 1cc1d0429da14a041a6240c6fce17e0d31cad8e2 (MariaDB 10.2.17, 10.3.9).
* | MDEV-23554 Wrong default value for foreign_key_checks variableAleksey Midenkov2020-08-252-2/+2
| | | | | | | | Sys_var_bit::session_save_default() ignored reverse_semantics property.
* | MDEV-23474 InnoDB fails to restart after SET GLOBAL innodb_log_checksums=OFFMarko Mäkelä2020-08-182-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Regretfully, the parameter innodb_log_checksums was introduced in MySQL 5.7.9 (the first GA release of that series) by mysql/mysql-server@af0acedd885eb7103e319f79d25fda7386ef1506 which partly replaced a parameter that had been introduced in 5.7.8 mysql/mysql-server@22ba38218e1d76c24f69b5a5595ad3bf5933acb0 as innodb_log_checksum_algorithm. Given that the CRC-32C operations are accelerated on many processor implementations (AMD64 with SSE4.2; since MDEV-22669 also on IA-32 with SSE4.2, POWER 8 and later, ARMv8 with some extensions) and by lookup tables when only generic SISD instructions are available, there should be no valid reason to disable checksums. In MariaDB 10.5.2, as a preparation for MDEV-12353, MDEV-19543 deprecated and ignored the parameter innodb_log_checksums altogether. This should imply that after a clean shutdown with innodb_log_checksums=OFF one cannot upgrade to MariaDB Server 10.5 at all. Due to these problems, let us deprecate the parameter innodb_log_checksums and honor it only during server startup. The command SET GLOBAL innodb_log_checksums will always set the parameter to ON.
* | Merge 10.1 into 10.2Marko Mäkelä2020-08-131-1/+1
|\ \ | |/
| * MDEV-20672 Inconsistent usage message for innodb_compression_algorithmMarko Mäkelä2020-08-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | The usage message for the innodb_compression_algorithm system variable did not list snappy, which was added as an optional compression algorithm in MariaDB 10.1.3 and might actually work since commit 90c52e5291b3ad0935df7da56ec0fcbf530733b4 (MDEV-12615) in MariaDB 10.1.24. Unfortunately, we will include also unavailable compression algorithms in the list, because ENUM parameters allow numeric values, and we do not want innodb_compression_algorithm=3 to change meaning depending on the way how the source code was compiled.
| * MDEV-23386: mtr: main.mysqld--help autosized table{-open,}-cach and ↵Daniel Black2020-08-102-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | max-connections Example of the failure: http://buildbot.askmonty.org/buildbot/builders/bld-p9-rhel7/builds/4417/steps/mtr/logs/stdio ``` main.mysqld--help 'unix' w17 [ fail ] Test ended at 2020-06-20 18:51:45 CURRENT_TEST: main.mysqld--help --- /opt/buildbot-slave/bld-p9-rhel7/build/mysql-test/main/mysqld--help.result 2020-06-20 16:06:49.903604179 +0300 +++ /opt/buildbot-slave/bld-p9-rhel7/build/mysql-test/main/mysqld--help.reject 2020-06-20 18:51:44.886766820 +0300 @@ -1797,10 +1797,10 @@ sync-relay-log-info 10000 sysdate-is-now FALSE system-versioning-alter-history ERROR -table-cache 421 +table-cache 2000 table-definition-cache 400 -table-open-cache 421 -table-open-cache-instances 1 +table-open-cache 2000 +table-open-cache-instances 8 tc-heuristic-recover OFF tcp-keepalive-interval 0 tcp-keepalive-probes 0 mysqltest: Result length mismatch ``` mtr: table_open_cache_basic autosized: Lets assume that >400 are available and that we can set the result back to the start value. All of these system variables are autosized and can generate MTR output differences. Closes #1527
* | Merge branch '10.1' into 10.2Oleksandr Byelkin2020-08-023-10/+10
|\ \ | |/
| * XtraDB 5.6.49-89.0Marko Mäkelä2020-07-302-2/+2
| | | | | | | | | | | | | | | | | | The only change between Percona XtraDB Server 5.6.48-88.0 and 5.6.49-89.0 (apart from the version number change) was percona/percona-server@25ec24092064c2ab95752705e592e0c038ec1111 which we had already addressed in commit 7c03edf2fe66855a8ce8f2575c3aaf66af975377 and commit c0fca2863bcbd7cd231f1aa747b4f8d999e3a00e.
| * MDEV-19232: Floating point precision / value comparison problemVarun Gupta2020-07-221-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | The issue occurs when the subquery_cache is enabled. When there is a cache miss the division was leading to a value with scale 9. In the case of cache hit the value returned was of scale 9 and due to the different values for the scales the where condition evaluated to FALSE, hence the output was incomplete. To fix this problem we need to round up the decimal to the limit mentioned in Item::decimals. This would make sure the values are compared with the same scale.
* | Merge 10.1 into 10.2Marko Mäkelä2020-07-142-4/+4
|\ \ | |/
| * XtraDB 5.6.48-88.0Marko Mäkelä2020-07-142-2/+2
| | | | | | | | | | | | The only InnoDB changes between Percona XtraDB Server 5.6.47-87.0 and 5.6.48-88.0 are related to InnoDB changes between MySQL 5.6.47 and MySQL 5.6.48, which we had already applied.
| * Update the InnoDB version number to 5.6.49Marko Mäkelä2020-07-143-3/+3
| | | | | | | | There were no InnoDB changes between MySQL 5.6.48 and MySQL 5.6.49.
* | MDEV-22058: Assertion `!is_set() || (m_status == DA_OK_BULK && ↵Rucha Deodhar2020-07-122-13/+13
| | | | | | | | | | | | | | | | is_bulk_op())' failed in Diagnostics_area::set_ok_status Error state is not stored in check_and_do_in_subquery_rewrites() when there is illegal combination of optimizer switches. So all the functions eventually return false. Thus the assetion failure.
* | Merge 10.1 into 10.2Marko Mäkelä2020-06-064-24/+24
|\ \ | |/
| * MDEV-22715: SIGSEGV in radixsort_for_str_ptr and in native_compare/my_qsort2 ↵Varun Gupta2020-06-054-24/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | (optimized builds) For DECIMAL[(M[,D])] datatype max_sort_length was not being honoured which was leading to buffer overflow while making the sort key. The fix to this problem would be to create sort keys for decimals with atmost max_sort_key bytes Important: The minimum value of max_sort_length has been raised to 8 (previously was 4), so fixed size datatypes like DOUBLE and BIGINIT are not truncated for lower values of max_sort_length.
* | Merge 10.1 into 10.2Marko Mäkelä2020-05-201-1/+1
|\ \ | |/
| * MDEV-22258 Limit innodb_encryption_threads to 255Marko Mäkelä2020-05-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For no good reason, innodb_encryption_threads was limited to 4,294,967,295. Expectedly, the server would crash if such an insane value was specified. Let us limit the maximum to 255. The encryption threads are not doing much useful work. They are basically only dirtying pages by performing dummy writes via the redo log. The encryption key rotation or the in-place addition or removal of encryption will take place in the page cleaner. In a quick test on a 20-core CPU (40 threads in total), the sweet spot on an otherwise idle server seemed to be innodb_encryption_threads=16 for the test encryption.encrypt_and_grep. The new limit 255 should be more than enough for even bigger servers.
* | MDEV-21336 Memory leaks related to innodb_debug_syncMarko Mäkelä2020-05-141-12/+0
| | | | | | | | | | | | | | | | | | | | This essentially reverts commit b393e2cb0c079b30563dcc87a62002c9c778643c. The leak might have been fixed, but because the DEBUG_SYNC instrumentation for InnoDB purge threads was reverted in 10.5 commit 5e62b6a5e06eb02cbde1e34e95e26f42d87fce02 as part of introducing a thread pool, it is easiest to revert the entire change.
* | Merge 10.1 into 10.2Marko Mäkelä2020-05-131-1/+1
|\ \ | |/
| * MDEV-22501 Various issues when using --innodb-data-file-size-debug=-1Marko Mäkelä2020-05-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 18ef02b04dfae21148c7397d088c7ffdfcd23c4e and has been filed as bug MDEV-22219.
* | Merge 10.1 into 10.2Marko Mäkelä2020-04-282-4/+4
|\ \ | |/
| * InnoDB 5.6.48Marko Mäkelä2020-04-283-3/+3
| |
| * XtraDB 5.6.47-87.0Marko Mäkelä2020-04-272-2/+2
| | | | | | | | | | | | | | The only change is a change of the version number. As noted in commit 02af6278fb7c7889a02d617eb23e82fe7967abd7 there were no changes to InnoDB between MySQL 5.6.46 and 5.6.47 either.
| * sysvars_server_* tests need to have performance schema enabledVicențiu Ciorbaru2020-04-131-0/+1
| | | | | | | | | | Tests will fail otherwise. Backport change from: 867809f23a8f09b1ac0aa8f9212ac8afd572efc
* | MDEV-20604: Duplicate key value is silently truncated to 64 characters in ↵Oleksandr Byelkin2020-04-0110-23/+23
| | | | | | | | | | | | print_keydup_error Added indication of truncated string for "s" and "M" formats
* | MDEV-18027: Running out of file descriptors and eventual crashOleksandr Byelkin2020-02-051-1/+1
| | | | | | | | For automatic number of opened files limit take into account number of table instances for table cache
View Lorry Controller Status