summaryrefslogtreecommitdiff
path: root/mysql-test
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-25284: Assertion `info->type == READ_CACHE || info->type == ↵bb-10.2-MDEV-25284Brandon Nesterenko2021-10-185-0/+310
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | WRITE_CACHE' failed Problem: ======== This patch addresses two issues. First, if a CHANGE MASTER command is issued and an error happens while locating the replica’s relay logs, the logs can be put into an invalid state where future updates fail and future CHANGE MASTER calls crash the server. More specifically, right before a replica purges the relay logs (part of the `CHANGE MASTER TO` logic), the relay log is temporarily closed with state LOG_TO_BE_OPENED. If the server errors in-between the temporary log closure and purge, i.e. during the function find_log_pos, the log should be closed. MDEV-25284 reveals the log is not properly closed. Second, upon issuing a RESET SLAVE ALL command, a slave’s GTID filters are not cleared (DO_DOMAIN_IDS, IGNORE_DOMIAN_IDS, IGNORE_SERVER_IDS). MySQL had a similar bug report, Bug #18816897, which fixed this issue to clear IGNORE_SERVER_IDS after issuing RESET SLAVE ALL in version 5.7. Solution: ========= To fix the first problem, the CHANGE MASTER error handling logic was extended to transition the relay log state to LOG_CLOSED from LOG_TO_BE_OPENED. To fix the second problem, the RESET SLAVE ALL logic is extended to clear the domain_id filter and ignore_server_ids. Reviewed By: ============ Andrei Elkin <andrei.elkin@mariadb.com>
* A clean-up patch for MDEV-23408: fixing test failure on Windowsbb-10.2-bar-MDEV-23408Alexander Barkov2021-10-152-8/+8
| | | | | | | | | Schema and table names in a veiw FRM files are: - in upper case on Linux - in lower case on Windows Using the LOWER() function when displaying an FRM file fragment, to avoid the OS-specific difference.
* MDEV-17964: Assertion `status == 0' failed in add_role_user_mapping_actionVicențiu Ciorbaru2021-10-152-0/+297
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This happens upon CREATE USER and DROP ROLE. The underlying problem is that our HASH implementation shuffles elements around when performing an update or delete. This means that when doing a scan through the HASH table by index, in search of elements to delete or update one must restart the scan to make sure nothing is missed if at least one delete / update happened. More specifically, what happened in this case: The hash has 131 element, DROP ROLE removes the element [119]. Its [119]->next was element [129], so [129] is moved to [119]. Now we need to compact the hash, removing the last element [130]. It gets one bit off its hash value and becomes element [2]. The existing element [2] is moved to [129], and old [130] is moved to [2]. We cannot simply move [130] to [129] and make [2]->next=130, it won't work if [2] is itself in the collision list and doesn't belong in [2]. The handle_grant_struct code assumed that it is safe to continue by only reexamining the currently modified / deleted element index, but that is not true. Missing to delete an element in the hash triggered the assertion in the test case. DROP ROLE would not clear all necessary role->role or role->user mappings. To fix the problem we ensure that the scan is restarted, only if an element was deleted / updated, similar to how bubble-sort keeps sorting until it finds no more elements to swap.
* MDEV-23408 Wrong result upon query from I_S and further Assertion ↵Alexander Barkov2021-10-148-0/+194
| | | | | | | | | | | | | | | | | | | | | | | | | | `!alias_arg || strlen(alias_arg->str) == alias_arg->length' failed with certain connection charset There were two independent problems which lead to the crash and to the non-relevant records returned in I_S queries: - The code in the I_S implementation was not secure about values with 0x00 bytes. It's fixed by using check_db_name() and check_table_name() inside make_table_name_list(), and by adding the test for 0x00 inside check_table_name(). - The code in Item_string::print() did not convert strings without introducers when restoring the CREATE VIEW statement from an Item tree. This made wrong literals inside the "query" line in the view FRM file in cases when the VIEW parse time character_set_client!=character_set_connection. That's fixed by adding a proper conversion. This change also fixed a similar problem in SHOW PROCEDURE CODE - the literals were displayed in wrong character set in SP instructions in cases when the SP parse time character_set_client!=character_set_connection.
* MDEV-26815 : galera.galera_ftwrl_drain fails with wrong errno 1146bb-10.2-MDEV-26815-galeraJan Lindström2021-10-132-12/+15
| | | | Add wait_conditions to stabilize
* MDEV-25925 Warning: Memory not freed: 32 on INSERT DELAYEDbb-10.2-bar-MDEV-25925Alexander Barkov2021-10-113-0/+39
| | | | | | | | | | | | | | | | Also fixes MDEV-24467 Memory not freed after failed INSERT DELAYED Description: In case of an error (e.g. data truncation) during mysql_insert() handling an INSERT DELAYED, the data type specific data in fields (e.g. Field_blob::value) is not taken over by the delayed writer thread. All fields in table_list->table are freed by free_root() immediately after mysql_insert(). To avoid a memory leak, we need to free the specific data before exiting mysql_insert() on error.
* MDEV-23269 SIGSEGV in ft_boolean_check_syntax_string on setting ↵bb-10.2-bar-MDEV-23269Alexander Barkov2021-10-115-0/+28
| | | | | | | | | | | | | | ft_boolean_syntax The crash happened because my_isalnum() does not support character sets with mbminlen>1. The value of "ft_boolean_syntax" is converted to utf8 in do_string_check(). So calling my_isalnum() is combination with "default_charset_info" was wrong. Adding new parameters (size_t length, CHARSET_INFO *cs) to ft_boolean_check_syntax_string() and passing self->charset(thd) as the character set.
* MDEV-24742 Server crashes in Charset::numchars / String::numcharsbb-10.2-bar-MDEV-24742Alexander Barkov2021-10-112-0/+28
| | | | | The crash happened because Item_aes_crypt::val_str() did not set the character set of the result.
* MDEV-18278 Misleading error message in error log upon failed table creationAleksey Midenkov2021-10-112-0/+14
| | | | | If error_reported is not set upper caller open_table_from_share() throws error ER_NOT_FORM_FILE itself via open_table_error().
* MDEV-14846 InnoDB: assertion on trx->state because of deadlock error ignoredAleksey Midenkov2021-10-113-0/+123
| | | | | | | | | | On deadlock transaction is rolled back (and trx->state is cleared) but SELECT continued the loop because evaluate_join_record() ignored the error status returned from lower join evaluation. val_int() does not return error status so it is checked by thd->is_error(). Test case was created by Thirunarayanan Balathandayuthapani <thiru@mariadb.com>
* MDEV-24454 fixup: Fix plugins.feedback_plugin_sendMarko Mäkelä2021-10-112-3/+19
| | | | | In commit 3690c549c6e72646ba74f6b4c83813ee4ac3aea4 this test was not adjusted.
* MDEV-25444: mysql --binary-mode is not able to replay some mysqlbinlog outputsbb-10.2-MDEV-25444Brandon Nesterenko2021-10-062-0/+224
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note: This patch backports commits 10cd281 and 1755ea4 from 10.3. 10cd281: Problem:- Some binary data is inserted into the table using Jconnector. When binlog dump of the data is applied using mysql client it gives syntax error. Reason:- After investigating it turns out to be a issue of mysql client not able to properly handle \\0 <0 in binary>. In all binary files where mysql client fails to insert these 2 bytes are common (0x5c00) Solution:- I have changed mysql.cc to include for the possibility that binary string can have \\0 in it 1755ea4: Changes on top of Sachin’s patch. Specifically: 1) Refined the parsing break condition to only change the parser’s behavior for parsing strings in binary mode (behavior of \0 outside of strings is unchanged). 2) Prefixed binary_zero_insert.test with ‘mysql_’ to more clearly associate the purpose of the test. 3) As the input of the test contains binary zeros (0x5c00), different text editors can visualize this sequence differently, and Github would not display it at all. Therefore, the input itself was consolidated into the test and created out of hex sequences to make it easier to understand what is happening. 4) Extended test to validate that the rows which correspond to the INSERTS with 0x5c00 have the correct binary zero data. Reviewed By: ============ Andrei Elkin <andrei.elkin@mariadb.com>
* MDEV-24978 crash with transaction on table with no PK and long fulltext columnbb-10.2-MDEV-24978-galerasjaakola2021-09-302-21/+99
| | | | | | | | | | If a table has no unique indexes, write set key information will be collected on all columns in the table. The write set key information has space only for max 3500 bytes for individual column, and if a varchar colummn of such non-primary key table is longer than this limit, currently a crash follows. The fix in this commit, is to truncate key values extracted from such long varhar columns to max 3500 bytes. This may potentially lead to false positive certification failures for transactions, which operate on separate cluster nodes, and update/insert/delete table rows, which differ only in the part of such long columns after 3500 bytes border. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
* Make innodb.innodb_defrag_stats more deterministicMarko Mäkelä2021-09-292-162/+143
| | | | | | Let us mask the actual values of the defragmentation-related fields, because they may vary. Also, remove the dependency on purge, and instead delete records by a ROLLBACK of INSERT.
* MDEV-24454 Crash at change_item_treebb-10.2-MDEV-24454Oleksandr Byelkin2021-09-274-0/+115
| | | | | | | | | | | | | Use in_sum_func (and so nest_level) only in LEX to which SELECT lex belong to Reduce usage of current_select (because it does not always point on the correct SELECT_LEX, for example with prepare. Change context for all classes inherited from Item_ident (was only for Item_field) in case of pushing down it to HAVING. Now name resolution context have to have SELECT_LEX reference if the context is present. Fixed feedback plugin stack usage.
* Remove test from galera_fulltext until MDEV-24978 is fixed.bb-10.2-jan-galeraJan Lindström2021-09-272-50/+21
|
* Revert MDEV-25114Marko Mäkelä2021-09-248-474/+28
| | | | | | Revert 88a4be75a5f3b8d59ac8f6347ff2c197813c05dc and 9d97f92febc89941784d17d59c60275e21140ce0, which had been prematurely pushed by accident.
* Revert "MDEV-24978 : SIGABRT in __libc_message"bb-10.2-MDEV-24978-fJan Lindström2021-09-242-51/+0
| | | | This reverts commit 30dea4599e44e3008fb9bc5fe79ab5747841f21f.
* MDEV-25114 Crash: WSREP: invalid state ROLLED_BACK (FATAL)sjaakola2021-09-248-28/+474
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is the plan D variant for fixing potetial mutex locking order exercised by BF aborting and KILL command execution. In this approach, KILL command is replicated as TOI operation. This guarantees total isolation for the KILL command execution in the first node: there is no concurrent replication applying and no concurrent DDL executing. Therefore there is no risk of BF aborting to happen in parallel with KILL command execution either. Potential mutex deadlocks between the different mutex access paths with KILL command execution and BF aborting cannot therefore happen. TOI replication is used, in this approach, purely as means to provide isolated KILL command execution in the first node. KILL command should not (and must not) be applied in secondary nodes. In this patch, we make this sure by skipping KILL execution in secondary nodes, in applying phase, where we bail out if applier thread is trying to execute KILL command. This is effective, but skipping the applying of KILL command could happen much earlier as well. This patch also fixes mutex locking order and unprotected THD member accesses on bf aborting case. We try to hold THD::LOCK_thd_data during bf aborting. Only case where it is not possible is at wsrep_abort_transaction before call wsrep_innobase_kill_one_trx where we take InnoDB mutexes first and then THD::LOCK_thd_data. This will also fix possible race condition during close_connection and while wsrep is disconnecting connections. Added wsrep_bf_kill_debug test case Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
* MDEV-26450: Corruption due to innodb_undo_log_truncatebb-10.2-MDEV-26450Marko Mäkelä2021-09-222-81/+5
| | | | | | | | | | | | | | | | | | | | | | | | | At least since commit 055a3334adc004bd3a897990c2f93178e6bb5f90 (MDEV-13564) the undo log truncation in InnoDB did not work correctly. The main issue is that during the execution of trx_purge_truncate_history() some pages of the newly truncated undo tablespace could be discarded. fsp_try_extend_data_file(): Apply the peculiar rounding of fil_space_t::size_in_header only to the system tablespace, whose size can be expressed in megabytes in a configuration parameter. Other files may freely grow by a number of pages. fseg_alloc_free_page_low(): Do allow the extension of undo tablespaces, and mention the file name in the error message. mtr_t::commit_shrink(): Implement crash-safe shrinking of a tablespace file. First, durably write the log, then shrink the file, and finally release the page latches of the rebuilt tablespace. Refactored from trx_purge_truncate_history(). log_write_and_flush_prepare(), log_write_and_flush(): New functions to durably write log during mtr_t::commit_shrink().
* MDEV-26636: InnoDB defragmentation statistics cause races on TEMPORARY TABLEMarko Mäkelä2021-09-182-115/+60
| | | | | | | | | | | | | | | | btr_defragment_save_defrag_stats_if_needed(): Do not save defragmentation statistics for temporary tables. They are exempt of defragmentation anyway (ha_innobase::optimize() never invokes defragmentation for them), and the user-visible names are not available inside InnoDB. Furthermore, InnoDB assumes that temporary tables are never accessed by other threads than the one that handles the session with which the temporary table is associated with. Furthermore, we simplify the test innodb.innodb_defrag_stats and include a test case that demonstrates that defragmentation statistics are no longer being saved for temporary tables.
* MDEV-15675 encryption.innodb_encryption failed in buildbot with timeoutbb-10.2-MDEV-15675Thirunarayanan Balathandayuthapani2021-09-172-3/+5
| | | | | Test case fail to include undo tablespace while waiting for the encryption thread to encrypt all existing tablespace
* Give less memory to get reliable error.Oleksandr Byelkin2021-09-162-3/+3
|
* Fix an occasional timeout in innodb.alter_partitionedMarko Mäkelä2021-09-112-0/+8
|
* MDEV-26537 InnoDB corrupts files due to incorrect st_blksize calculationMarko Mäkelä2021-09-101-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The st_blksize returned by fstat(2) is not documented to be a power of 2, like we assumed in commit 58252fff15acfe7c7b0452a87e202e3f8e454e19 (MDEV-26040). While on Linux, the st_blksize appears to report the file system block size (which hopefully is not smaller than the sector size of the underlying block device), on FreeBSD we observed st_blksize values that might have been something similar to st_size. Also IBM AIX was affected by this. A simple test case would lead to a crash when using the minimum innodb_buffer_pool_size=5m on both FreeBSD and AIX: seq -f 'create table t%g engine=innodb select * from seq_1_to_200000;' \ 1 100|mysql test& seq -f 'create table u%g engine=innodb select * from seq_1_to_200000;' \ 1 100|mysql test& We will fix this by not trusting st_blksize at all, and assuming that the smallest allowed write size (for O_DIRECT) is 4096 bytes. We hope that no storage systems with larger block size exist. Anything larger than 4096 bytes should be unlikely, given that it is the minimum virtual memory page size of many contemporary processors. MariaDB Server on Microsoft Windows was not affected by this. While the 512-byte sector size of the venerable Seagate ST-225 is still in widespread use, the minimum innodb_page_size is 4096 bytes, and innodb_log_file_size can be set in integer multiples of 65536 bytes. The only occasion where InnoDB uses smaller data file block sizes than 4096 bytes is with ROW_FORMAT=COMPRESSED tables with KEY_BLOCK_SIZE=1 or KEY_BLOCK_SIZE=2 (or innodb_page_size=4096). For such tables, we will from now on preallocate space in integer multiples of 4096 bytes and let regular writes extend the file by 1024, 2048, or 3072 bytes. The view INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES.FS_BLOCK_SIZE should report the raw st_blksize. For page_compressed tables, the function fil_space_get_block_size() will map to 512 any st_blksize value that is larger than 4096. os_file_set_size(): Assume that the file system block size is 4096 bytes, and only support extending files to integer multiples of 4096 bytes. fil_space_extend_must_retry(): Round down the preallocation size to an integer multiple of 4096 bytes.
* fix main.truncate failures in --embeddedSergei Golubchik2021-09-094-54/+55
|
* MDEV-25325 built-in documentation for performance_schema tablesHaidong Ji2021-09-07107-1582/+3072
| | | | | | Improve documentation of performance_schema tables by appending COLUMN comments to tables. Additionally improve test coverage and update corresponding tests.
* MDEV-23365: Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())'bb-10.2-MDEV-23365Rucha Deodhar2021-09-062-0/+51
| | | | | | | | | | | failed upon killed TRUNCATE Note: This is a backport of 1cb4caa66d5fd2a9bc095d68988324b7b358d70f from 10.3 Analysis: Assertion failure happens because less session memory is set and so table can't be reopened. So the statement can't be used. This error goes unreported. Fix: Return the error state.
* MDEV-12055 binlog.binlog_stm_ctype_ucs postfixDaniel Black2021-09-051-1/+1
| | | | | | | | | | | | | | | | | | | | As highlighted in https://bugs.gentoo.org/807995, people occasionaly run tests in the 20:00->23:59:59 time range. Fixes 265e3253f1e5218c8f85f1c412575069cb15f2c0 binlog.binlog_stm_ctype_ucs 'mix' w1 [ fail ] Test ended at 2021-08-11 22:55:35 CURRENT_TEST: binlog.binlog_stm_ctype_ucs --- /var/tmp/portage/dev-db/mariadb-10.5.11/work/mysql/mysql-test/suite/binlog/r/binlog_stm_ctype_ucs.result 2021-06-18 18:19:11.000000000 +0800 +++ /var/tmp/portage/dev-db/mariadb-10.5.11/work/mysql/mysql-test/suite/binlog/r/binlog_stm_ctype_ucs.reject 2021-08-11 22:55:34.993447479 +0800 @@ -76,21 +76,21 @@ /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; DELIMITER /*!*/; # at # -#YYMMDD HH:MM:SS server id # end_log_pos # CRC32 XXX Start: binlog v 4, server v #.##.## created YYMMDD HH:MM:SS +#210811 22:55:34 server id # end_log_pos # CRC32 XXX Start: binlog v 4, server v #.##.## created 210811 22:55:34
* MDEV-26518 ; Galera incorrectly handles primary or unique keys with any ↵bb-10.2-MDEV-26517Jan Lindström2021-09-024-0/+108
| | | | | | | multi-byte character set We need to set temporary buffer large enough to fit also multi-byte characters.
* MDEV-26517 : Galera test failure on galera_fk_cascade_delete_debugJan Lindström2021-09-021-1/+1
| | | | | Move --error on --reap where it belongs and take a account that there could be different return codes.
* MDEV-26521 Remove mdev-504.testVladislav Vaintroub2021-09-013-105/+0
| | | | | | | | This stress tests fails on not sufficiently tweaked windows boxes,due to rapid succession of connects and disconnects, making Windows run out of ephemeral ports. Approved by author of the test (the author is happy to see it removed)
* mtr: fix the check where a combination is pre-selectedSergei Golubchik2021-08-292-17/+11
| | | | | | | | | if all options from a combination from the combinations file are already present in the server's list of options, then don't try to run tests in other combinations from this file. old behavior was: if at least one option from a combination is already present in the list...
* Disable 2 commonly failing innodb_gis testsMarko Mäkelä2021-08-231-0/+2
|
* MDEV-20931 fixup: innodb.import_corrupted test case cleanupMarko Mäkelä2021-08-181-0/+1
|
* MDEV-26131 fixup: ./mtr --embedded encryption.innodb_importMarko Mäkelä2021-08-181-0/+1
|
* MDEV-20931 ALTER...IMPORT can crash the serverEugene Kosov2021-08-172-0/+98
| | | | | Main idea: don't log-and-crash but propogate error to the upper layers of stack to handle it and show to a user.
* MDEV-26131 SEGV in ha_innobase::discard_or_import_tablespaceThirunarayanan Balathandayuthapani2021-08-165-29/+70
| | | | | | | | | | | | | | | | | Import operation without .cfg file fails when there is mismatch of index between metadata table and .ibd file. Moreover, MDEV-19022 shows that InnoDB can end up with index tree where non-leaf page has only one child page. So it is unsafe to find the secondary index root page. This patch does the following when importing the table without .cfg file: 1) If the metadata contains more than one index then InnoDB stops the import operation and report the user to drop all secondary indexes before doing import operation. 2) When the metadata contain only clustered index then InnoDB finds the index id by reading page 0 & page 3 instead of traversing the whole tablespace.
* MDEV-18734 ASAN heap-use-after-free upon sorting by blob column from ↵Aleksey Midenkov2021-08-054-0/+182
| | | | | | | | | | | | | | | | | | | partitioned table ha_partition stores records in array of m_ordered_rec_buffer and uses it for prio queue in ordered index scan. When the records are restored from the array the blob buffers may be already freed or rewritten. The solution is to take temporary ownership of cached blob buffers via String::swap(). When the record is restored from m_ordered_rec_buffer the ownership is returned to table fields. Cleanups: init_record_priority_queue(): removed needless !m_ordered_rec_buffer check as there is same assertion few lines before. dbug_print_row() for arbitrary row pointer
* MDEV-26220 Server crashes with indexed by prefix virtual columnmariadb-10.2.40Nikita Malyavin2021-08-023-0/+34
| | | | | | | | | | | | | | | Server crashes in Field::register_field_in_read_map upon select from partitioned table with indexed by prefix virtual column. After several read-mark fixes a problem has surfaced: Since KEY (c(10),a) uses only a prefix of c, a new field is created, duplicated from table->field[3], with a new length. However, vcol_inco->expr is not copied. Therefore, (*key_info)->key_part[i].field->vcol_info->expr was left NULL in ha_partition::index_init(). Solution: copy vcol_info from table field when it's set up.
* Revert "MDEV-26220 Server crashes with indexed by prefix virtual column"Oleksandr Byelkin2021-08-023-34/+0
| | | | This reverts commit 9b8e207ce03b2ab7a766348738055be9520561bd.
* MDEV-23752 SHOW EXPLAIN FOR thd waits for sleepSergei Golubchik2021-07-312-19/+25
| | | | | | | | | | | | fix main.processlist_notembedded test * before EXPLAINing `select sleep` wait for select to start (fixes "Target is not running an EXPLAINable command") * after killing sleep, wait for it to die (fixes test failures on --repeat when old sleep shows on a test rerun) * unify with 10.3, copy minor changes from there (`--echo End of 5.5` vs `--echo # End of 5.5`, etc)
* MDEV-20154 Assertion `len <= col->len | ...` failed in row_merge_buf_addNikita Malyavin2021-07-292-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | len was containing garbage, since vctempl->mysql_col_offset was containing old value while calling row_mysql_store_col_in_innobase_format from innobase_get_computed_value(). It was not updated after the first ALTER TABLE call, because it's INPLACE logic considered there's nothing to update, and exited immediately from ha_innobase::inplace_alter_table(). However, vcol metadata needs an update, since vcols structure is changed in mysql record. The regression was introduced by 12614af1fe. There, refcount==1 condition was removed, which turned out to be crucial, though racy. The idea was to update vc_templ after each (sequencing) ALTER TABLE. We should do the same another way, and there may be a plenty of solutions, but the simplest one is to add a following condition: if vcol structure is changed, drop vc_templ; it will be recreated on next ha_innobase::open() call. in prepare_inplace_alter_table. It is safe, since innodb inplace changes require at least HA_ALTER_INPLACE_SHARED_LOCK_AFTER_PREPARE, which guarantee MDL_EXCLUSIVE on this stage. alter_templ_needs_rebuild() also has to track the columns not indexed, to keep vc_templ correct. Note that vc_templ is always kept constructed and available after ha_innobase::open() call, even on INSERT, though no virtual columns are evaluated during that statement inside innodb. In the test case suplied, it will be recreated on the second ALTER TABLE.
* MDEV-26220 Server crashes with indexed by prefix virtual columnNikita Malyavin2021-07-283-0/+34
| | | | | | | | | | | | | | | | | Server crashes in Field::register_field_in_read_map upon select from partitioned table with indexed by prefix virtual column. After several read-mark fixes a problem has surfaced: Since KEY (c(10),a) uses only a prefix of c, a new field is created, duplicated from table->field[3], with a new length. However, vcol_inco->expr is not copied. Therefore, (*key_info)->key_part[i].field->vcol_info->expr was left NULL in ha_partition::index_init(). Solution: initialize vcols before key initialization Also key initialization is moved to a function.
* MDEV-26062 : InnoDB: WSREP: referenced FK check fail: Lock wait index ↵Jan Lindström2021-07-262-0/+92
| | | | | | | | | `PRIMARY` table `schema`.`child_table` Problem was that not all normal error codes where not handled after wsrep_row_upd_check_foreign_constraints() call. Furhermore, debug assertion did not contain all normal error cases. Changed ib:: calls to WSREP_ calls to use wsrep instrumentation.
* MDEV-25998 InnoDB removes the tablespace from default encrypt list earlyThirunarayanan Balathandayuthapani2021-07-261-18/+0
| | | | | | | | | | | | | | | | | | | | | | | | | Problem: ========= As a part of MDEV-14398 patch, InnoDB added and removed the tablespace from default encrypt list. But InnoDB removes the tablespace from the default encrypt list too early due to i) other encryption thread working on the tablespace ii) When tablespace is being flushed at the end of key rotation InnoDB fails to decrypt/encrypt the tablespace since the tablespace removed too early and it leads to test case failure. Solution: ========= Avoid the removal of tablespace from default_encrypt_list only when 1) Another active encryption thread working on tablespace 2) Eligible for tablespace key rotation 3) Tablespace is in flushing phase Removed the workaround in encryption.innodb_encryption_filekeys test case.
* Some tests can take very long time when run with valgrindElena Stepanova2021-07-245-0/+13
| | | | | | | | | | Set tests to non-valgrind: oqgraph.social encryption.innodb-page_encryption binlog_encryption.encrypted_master innodb.innodb-page_compression_lz4 main.lock_multi_bug38499 main.lock_multi_bug38691
* MDEV-26228 ASAN heap-use-after-free with ON UPDATE CASCADEMarko Mäkelä2021-07-232-0/+6
| | | | | | | | | | | | | | | In commit 83d2e0841ee30727c609f23957cc592399a3aca4 (MDEV-24041) we failed to notice that in addition to the bug with DELETE and ON DELETE CASCADE, there is another bug with UPDATE and ON UPDATE CASCADE. row_ins_foreign_fill_virtual(): Use the correct memory heap for everything that will be reachable from the cascade->update that we return to the caller. Note: It is correct to use the shorter-lived cascade->heap for rec_get_offsets(), because that memory will be abandoned when row_ins_foreign_fill_virtual() returns.
* MDEV-26080 fixup: fixed .result file for galera_roles test (one word must be ↵Julius Goryavsky2021-07-231-2/+2
| | | | enclosed in single quotes).
* MDEV-26202 Unexpected failure with query using indirectly a recursive CTE twiceIgor Babaev2021-07-222-0/+36
| | | | | This bug was fixed by the patch for bug MDEV-26025. Only a new test case is added here.
View Lorry Controller Status