summaryrefslogtreecommitdiff
path: root/mysql-test/suite
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-23328 Server hang due to Galera lock conflict resolutionJan Lindström2021-11-012-7/+13
| | | | | * Fix error handling NULL-pointer reference * Add mtr-suppression on galera_ssl_upgrade
* MDEV-23328 Server hang due to Galera lock conflict resolutionsjaakola2021-10-298-28/+122
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mutex order violation when wsrep bf thread kills a conflicting trx, the stack is wsrep_thd_LOCK() wsrep_kill_victim() lock_rec_other_has_conflicting() lock_clust_rec_read_check_and_lock() row_search_mvcc() ha_innobase::index_read() ha_innobase::rnd_pos() handler::ha_rnd_pos() handler::rnd_pos_by_record() handler::ha_rnd_pos_by_record() Rows_log_event::find_row() Update_rows_log_event::do_exec_row() Rows_log_event::do_apply_event() Log_event::apply_event() wsrep_apply_events() and mutexes are taken in the order lock_sys->mutex -> victim_trx->mutex -> victim_thread->LOCK_thd_data When a normal KILL statement is executed, the stack is innobase_kill_query() kill_handlerton() plugin_foreach_with_mask() ha_kill_query() THD::awake() kill_one_thread() and mutexes are victim_thread->LOCK_thd_data -> lock_sys->mutex -> victim_trx->mutex 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 also fixed unprotected calls to wsrep_thd_abort that will use wsrep_abort_transaction. This is fixed by holding THD::LOCK_thd_data while we abort transaction. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
* MDEV-26866 FOREIGN KEY…SET NULL corrupts an index on a virtual columnNikita Malyavin2021-10-282-0/+384
| | | | | | | | | | | | The initial test case for MySQL Bug #33053297 is based on mysql/mysql-server@27130e25078864b010d81266f9613d389d4a229b. innobase_get_field_from_update_vector is not a suitable function to fetch updated row info, as well as parent table's update vector is not always suitable. For instance, in case of DELETE it contains undefined data. castade->update vector seems to be good enough to fetch all base columns update data, and besides faster, and less error-prone.
* Fix tests for PLUGIN_PARTITION=NOMarko Mäkelä2021-10-271-0/+1
|
* 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.
* MDEV-26556 An improper locking bug(s) due to unreleased lock.bb-10.2-mdev-26556-hfAlexey Botchkov2021-10-252-0/+6
| | | | Get rid of the global big_buffer.
* MDEV-19129: Xcode compatibility update: mysql-test-run.pl: rename ↵Sergei Krivonos2021-10-211-1/+1
| | | | $opt_vs_config to $multiconfig to use with other cmake multiconfig generators
* MDEV-26865: Add test case and instrumentationMarko Mäkelä2021-10-212-0/+295
| | | | | | | | | Based on mysql/mysql-server@bc9c46bf2894673d0df17cd0ee872d0d99663121 but without sleeps. The test was verified to hit the debug assertion if the change to fts_add_doc_by_id() in commit 2d98b967e31623d9027c0db55330dde2c9d1d99a was reverted.
* MDEV-19522 InnoDB commit fails when FTS_DOC_ID value is greater than 4294967295Thirunarayanan Balathandayuthapani2021-10-214-4/+39
| | | | | | | | | | | | | | | | | | | | | | | InnoDB commit fails when consecutive FTS_DOC_ID value is greater than 4294967295. Fix is that InnoDB should remove the delta FTS_DOC_ID value limitations and fts should encode 8 byte value, remove FTS_DOC_ID_MAX_STEP variable. Replaced the fts0vlc.ic file with fts0vlc.h fts_encode_int(): Should be able to encode 10 bytes value fts_get_encoded_len(): Should get the length of the value which has 10 bytes fts_decode_vlc(): Add debug assertion to verify the maximum length allowed is 10. mach_read_uint64_little_endian(): Reads 64 bit stored in little endian format Added a unit test case which check for minimum and maximum value to do the fts encoding
* MDEV-22627 fixup: Cover also ALTER TABLE...ALGORITHM=INPLACEMarko Mäkelä2021-10-202-0/+17
|
* MDEV-22627 Failing assertion: dict_tf2_is_valid(flags, flags2)Marko Mäkelä2021-10-203-0/+40
| | | | | | | | | | | | | create_table_info_t::innobase_table_flags(): Refuse to create a PAGE_COMPRESSED table with PAGE_COMPRESSION_LEVEL=0 if also innodb_compression_level=0. The parameter value innodb_compression_level=0 was only somewhat meaningful for testing or debugging ROW_FORMAT=COMPRESSED tables. For the page_compressed format, it never made any sense, and the check in dict_tf_is_valid_not_redundant() that was added in 72378a25830184f91005be7e80cfb28381c79f23 (MDEV-12873) would cause the server to crash.
* MDEV-26262 frm is corrupted after ER_EXPRESSION_REFERS_TO_UNINIT_FIELDNikita Malyavin2021-10-203-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | This is a duplicate of MDEV-18278 89936f11e965, but I will add an additional assertion Description: The frm corruption should not be reported during CREATE TABLE. Normally it doesn't, and the data to fill TABLE is taken by open_table_from_share call. However, the vcol data is stored as SQL string in table->s->vcol_defs.str and is anyway parsed on each table open. It is impossible [or hard] to avoid, because it's hard to clone the expression tree in general (it's easier to parse). Normally parse_vcol_defs should only fail on semantic errors. If so, error_reported is set to true. Any other failure is not expected during table creation. There is either unhandled/unacknowledged error, or something went really wrong, like memory reject. This all should be asserted anyway. Solution: * Set *error_reported=true for the forward references check; * Assert for every unacknowledged error during table creation.
* MDEV-14804 innodb.update_time failed in buildbot with wrong resultMarko Mäkelä2021-10-193-15/+4
| | | | | Let us use a minimal-size buffer pool to ensure that page flushing will be slow enough so that LRU eviction cannot be avoided.
* 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>
* 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-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-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-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-272-0/+23
| | | | | | | | | | | | | 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
* 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.
* 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-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.
* 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-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-243-0/+8
| | | | | | | | | | 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-26203 CREATE INDEX may enforce incorrect maximum column lengthMarko Mäkelä2021-07-222-7/+43
| | | | | | | | | | ha_innobase::prepare_inplace_alter_table(): Unless the table is being rebuilt, determine the maximum column length based on the current ROW_FORMAT of the table. When TABLE_SHARE (and the .frm file) contains no explicit ROW_FORMAT, InnoDB table creation or rebuild will use innodb_default_row_format. Based on mysql/mysql-server@3287d33acdc4260806a2a407ca15e9d1e04dddcb
* MDEV-25361 fixup: Fix integer type mismatchMarko Mäkelä2021-07-222-8/+5
| | | | | | | | | | InnoDB tablespace identifiers and page numbers are 32-bit numbers. Let us use a 32-bit type for them in innochecksum. The changes in commit 1918bdf32cdbd1f190cc4479f4076ee4a467f25d broke the build on 32-bit Windows. Thanks to Vicențiu Ciorbaru for an initial version of this fixup.
View Lorry Controller Status