- 28 Jan, 2022 3 commits
-
-
Sergei Golubchik authored
fix it for Aria too
-
Monty authored
- Revert wrongly record embedded result files. These were either recorded with normal server (not embedded) or an embedded server with not default compile option. This can be seen that the committed result file had replication variables which should never happen. - Reverted back change of include/is_embedded.inc. One cannot check for $MYSQL_EMBEDDED as this only tells if there exists an embedded server, not if the current server we are testing is the embedded server. This could easily be verified by doing 'mtr sys_vars.sysvars_server_embedded'. This would fail with a wrong result instead of being marked as skipped as --embedded was not used.
-
Monty authored
This happens when compiled with HAVE_EMBEDDED_PRIVILEGE_CONTROL. There is a lot of other problems with the above option that should be fixed at some point
-
- 27 Jan, 2022 6 commits
-
-
Monty authored
-
Monty authored
This avoids printing the error "mysqld: file-key-management-filename is not set" which can happen if the file-key-management pluging is statically compiled
-
Monty authored
Removed the option as it safe to always create the file when we have created the MariaDB data directories. This fixes this issue not only for debian but for all MariaDB users.
-
Monty authored
This patch let's you specify not only user to use but also group that MariaDB should use. Original patch: https://github.com/openSUSE/mysql-packaging/blob/master/patches/mysql-patches/mariadb-10.2.3-group.patch Author: Kristyna Streitova Reviewer: monty@mariadb.org
-
Andrei authored
-
Andrei authored
The assert was caused by an error of XA transaction that had BINLOG 'base64_string' statement. The statement failed because of lack of checking whether the encoded replication event was handled by the slave applier thread. If it's not the slave applier no error should be generated, but it was in this case, see a test added. Fixed along with the idea borrowed the upstream to introduce a check of which applier executes the replication event and do not report any error if the applier is a regular server client.
-
- 26 Jan, 2022 7 commits
-
-
Daniel Black authored
Prevent the error: setroubleshoot[23678]: SELinux is preventing /usr/libexec/mysqld from read access on the file core_pattern. Reading of the core pattern occurs on crash as added in MDEV-15051 RHEL-7.7 $ ls -laZ /proc/sys/kernel/core_pattern -rw-r--r--. root root system_u:object_r:usermodehelper_t:s0 /proc/sys/kernel/core_pattern
-
Daniel Black authored
mtr is checking the wrong path for the embedded executable on out of tree builds. The is_embedded.inc tests are also checking the version rather than the MTR MYSQL_EMBEDDED environment variable. As a result, a few tests are out of date in the result recordings.
-
Daniel Black authored
For compatibility this is under an extra option --upgrade-info The goal here is to install a data directory with the required info to let mysql_upgrade know that an upgrade isn't required.
-
Marko Mäkelä authored
-
Oleksandr Byelkin authored
-
Vladislav Vaintroub authored
-
Lena Startseva authored
MDEV-8652: Partitioned table creation problem when creating from procedure context twice in same session The problem was solved in in MDEV-7990, this commit contains only test
-
- 25 Jan, 2022 2 commits
-
-
Brandon Nesterenko authored
This patch addresses two problems with rpl.rpl_seconds_behind_master_spike First, --sync_slave_with_master / select master_pos_wait seems to have a bug where it will hang after all master events have been executed. This patch removes the sync_slave_with_master command from the test, where it not required anyway as it is used to declare explicit cleanup Second, the test uses timestamps to ensure that the Seconds_Behind_Master value does not point to a time too far in the past. The checks of these timestamps were too strict, because they could be slightly inconsistent with the master and the SBM would be counted as invalid when it was actually correct. To fix this, a slight buffer was added to the check to ensure the value is valid but still does not point too far in the past Reviewed By: =========== Andrei Elkin <andrei.elkin@mariadb.com>
-
Alexey Botchkov authored
MDEV-25917 create table like fails if source table is partitioned and engine is myisam or aria with data directory. Create table like removes data_file_path/index_file_path from the thd->work_partition_info.
-
- 24 Jan, 2022 2 commits
-
-
Oleksandr Byelkin authored
-
Sergei Golubchik authored
MDEV-24088 Assertion in InnoDB's FTS code may be triggered by a repeated words fed to simple_parser plugin increment `position` for every word, because the plugin doesn't (FTS API doesn't use positions that InnoDB FTS relies on)
-
- 22 Jan, 2022 3 commits
-
-
Marko Mäkelä authored
-
Jan Lindström authored
Remove output if wsrep is not enabled.
-
Dmitry Shulga authored
MDEV-20516: Assertion `!lex->proc_list.first && !lex->result && !lex->param_list.elements' failed in mysql_create_view Execution of the CREATE VIEW statement sent via binary protocol where the flags of the COM_STMT_EXECUTE request a cursor to be opened before running the statement results in an assert failure. This assert fails since the data member thd->lex->result has not null value pointing to an instance of the class Select_materialize. The data member thd->lex->result is assigned a pointer to the class Select_materialize in the function mysql_open_cursor() that invoked in case the packet COM_STMT_EXECUTE requests a cursor to be opened. After thd->lex->result is assigned a pointer to an instance of the class Select_materialize the function mysql_create_view() is called (indirectly via the function mysql_execute_statement()) and the assert fails. The assert DBUG_ASSERT(!lex->proc_list.first && !lex->result && !lex->param_list.elements); was added by the commit 591c06d4. Unfortunately , the condition !lex->result was specified incorrect. It was supposed that the thd->lex->result is set only by parser on handling the clauses SELECT ... INTO but indeed it is also set inside mysql_open_cursor() and that fact was missed by the assert's condition. So, the fix for this issue is to just remove the condition !lex->result from the failing assert.
-
- 21 Jan, 2022 6 commits
-
-
Eugene Kosov authored
It's misleading to compare and write to user number of columns and fields. Thus, it would be better to remove that check and let use see a subsequent error message about missing or mispaced column. row_import::match_schema(): remove misleading check
-
Maheedhar PV authored
Changed the grouping and decimal separator for spanish locales as per ICU. Change-Id: I5d80fa59d3e66372d904e17c22c532d4dd2c565b
-
Sergei Golubchik authored
also fix a comment, and update a macro just in case
-
Sergei Golubchik authored
-
Marko Mäkelä authored
The InnoDB DATA DIRECTORY attribute is not implemented via symbolic links but something similar, *.isl files that contain the names of data files. InnoDB failed to ignore the DATA DIRECTORY attribute even though the server was started with --skip-symbolic-links. Native ALTER TABLE in InnoDB will retain the DATA DIRECTORY attribute of the table, no matter if the table will be rebuilt or not. Generic ALTER TABLE (with ALGORITHM=COPY) as well as TRUNCATE TABLE will discard the DATA DIRECTORY attribute. All tests have been run with and without the ./mtr option --mysqld=--skip-symbolic-links and some tests that use the InnoDB DATA DIRECTORY attribute have been adjusted for this.
-
Sergei Petrunia authored
Add a --rocksdb_ignore_datadic_errors plugin option for MyRocks. The default is 0, and this means MyRocks will call abort() if it detects a DDL mismatch. Setting rocksdb_ignore_datadic_errors=1 makes MyRocks to try to ignore the errors and allow to start the server for repairs.
-
- 20 Jan, 2022 8 commits
-
-
Sergei Petrunia authored
In ha_rocksdb::open(), check if the number of indexes seen from the SQL layer matches the number of indexes in the internal MyRocks data dictionary. Produce an error if there is a mismatch. (If we don't produce this error, we are likely to crash as soon as we attempt to use an index)
-
Monty authored
-
Monty authored
Code copied from 10.6
-
Monty authored
MDEV-27107 prevent two mariadb-upgrade running in parallel MDEV-27279 mariadb_upgrade add --check-if-upgrade-is-needed / restrict tests to major version Code is based of pull request from Daniel Black, but with a several extensions. - mysql_upgrade now locks the mysql_upgrade file with my_lock() (Advisory record locking). This ensures that two mysql_upgrades cannot be run in parallel. - Added --check-if-upgrade-is-needed to mysql_upgrade. This will return 0 if one has to run mysql_upgrade. Other changes: - mysql_upgrade will now immediately exit if the major version and minor version (two first numbers in the version string) is same as last run. Before this change mysql_upgrade was run if the version string was different from last run. - Better messages when there is no need to run mysql_upgrade. - mysql_upgrade --verbose now prints out a lot more information about the version checking. - mysql_upgrade --debug now uses default debug arguments if there is no option to --debug - "MySQL" is renamed to MariaDB in the messages - mysql_upgrade version increased to 2.0 Notes Verifying "prevent two mariadb-upgrade running in parallel" was done in a debugger as it would be a bit complex to do that in mtr. Reviewer: Danial Black <daniel@mariadb.org>
-
Dmitry Shulga authored
-
Thirunarayanan Balathandayuthapani authored
- InnoDB change buffer doesn't support spatial index. Spatial index should avoid change the buffer bitmap page when the page split happens.
-
Dmitry Shulga authored
Mixed declarations and code is not allowed for C90 so fix it to avoid compilation break on some platforms.
-
Daniel Black authored
Database names are 64 utf8 characters per the system tables that refer to them. The current database() function is returning 34 characters. The result of limiting this function results to max length of 34 became apparent when used in a UNION ALL where the results are truncated to 34 characters. For (uninvestigated) reasons, SELECT DATABASE() on its own would always return the right number of characters. Thanks Alexander Barkov for the review. Thanks dave for noticing the bug in the stackexchange post https://dba.stackexchange.com/questions/306183/why-is-my-database-name-truncated
-
- 19 Jan, 2022 3 commits
-
-
Dmitry Shulga authored
Running a query using cursor could lead to a server crash on building a temporary table used for handling the query. For example, the following cursor DECLARE cur1 CURSOR FOR SELECT t2.c1 AS c1 FROM t1 LEFT JOIN t2 ON t1.c1 = t2.c1 WHERE EXISTS (SELECT 1 FROM t1 WHERE c2 = -1) ORDER BY c1; declared and executed inside a stored routine could result in server crash on creating a temporary table used for handling the ORDER BY clause. Crash occurred on attempt to create the temporary table's fields based on fields whose data located in a memory root that already freed. It happens inside the function return_zero_rows() where the method Select_materialize::send_result_set_metadata() is invoked for cursor case. This method calls the st_select_lex_unit::get_column_types() in order to get a list of items with types of columns for the temporary table being created. The method st_select_lex_unit::get_column_types() returns first_select()->join->fields in case it is invoked for a cursor. Unfortunately, this memory has been already deallocated bit earlier by calling join->join_free(); inside the function return_zero_rows(). In case the query listed in the example is run in conventional way (without using cursor) the method st_select_lex_unit::get_column_types() returns first_select()->item_list that is not touched by invocation of the method join->join_free() so everything is fine for that. So, to fix the issue the resources allocated for the JOIN class should be released after any activities with the JOIN class has been completed, that is as the last statement before returning from the function return_zero_rows(). This patch includes tests both for the case when a cursor is run explicitly from within a stored routine and for the case when a cursor is opened implicitly as prescribed by the STMT_ATTR_CURSOR_TYPE attribute of binary protocol (the case of prepared statement).
-
Anel Husakovic authored
- Cherry-pick 2fcff310 (MDEV-21902) - Closed PR #1145 Reviewed by: holyfoot@mariadb.com
-
Daniel Black authored
.. to be the same as startup. In resolving MDEV-27461, BUF_LRU_MIN_LEN (256) is the minimum number of pages for the innodb buffer pool size. Obviously we need more than just flushing pages. Taking the 16k page size and its default minimum, an extra 25% is needed on top of the flushing pages to make a workable buffer pool. The minimum innodb_buffer_pool_chunk_size (1M) restricts the minimum otherwise we'd have a pool made up of different chunk sizes. The resulting minimum innodb buffer pool sizes are: Page Size, Previously minimum (startup), with change. 4k 5M 2M 8k 5M 3M 16k 5M 5M 32k 24M 10M 64k 24M 20M With this patch, SET GLOBAL innodb_buffer_pool_size minimums are enforced. The evident minimum system variable size for innodb_buffer_pool_size is 2M, however this is only setable if using 4k page size. As the order of the page_size and buffer_pool_size aren't fixed, we can't hide this change. Subsequent changes: * innodb_buffer_pool_resize_with_chunks.test - raised of pool resize due to new minimums. Chunk size also needed increase as the test was for pool_size < chunk_size to generate a warning. * Removed srv_buf_pool_min_size and replaced use with MYSQL_SYSVAR_NAME(buffer_pool_size).min_val * Removed srv_buf_pool_def_size and replaced constant defination in MYSQL_SYSVAR_LONGLONG(buffer_pool_size) * Reordered ha_innodb to allow for direct use of MYSQL_SYSVAR_NAME(buffer_pool_size).min_val * Moved buf_pool_size_align into ha_innodb to access to MYSQL_SYSVAR_NAME(buffer_pool_size).min_val * loose-innodb_disable_resize_buffer_pool_debug is needed in the innodb.restart.opt test so that under debug mode, resizing of the innodb buffer pool can occur.
-