summaryrefslogtreecommitdiff
path: root/storage/innobase/handler
Commit message (Collapse)AuthorAgeFilesLines
* Merge 10.2 into 10.3Marko Mäkelä2021-05-241-11/+10
|\
| * MDEV-25663 Double free of transaction during truncate operationThirunarayanan Balathandayuthapani2021-05-241-8/+2
| | | | | | | | | | - Patch addresses the problem to fix double free of transaction if it is own transaction.
| * MDEV-25663 Double free of transaction during truncate operationThirunarayanan Balathandayuthapani2021-05-231-1/+6
| | | | | | | | | | | | | | InnoDB truncate table fails to load the fts stopword table into cache. In that case, InnoDB double frees the truncate creation transaction. InnoDB should free the transaction which was created inside ha_innobase::create.
| * MDEV-25664 Potential hang in purge for virtual columnsMarko Mäkelä2021-05-211-2/+4
| | | | | | | | | | | | | | | | | | ha_innobase::open(): If the table is only being opened by purge for evaluating virtual column values, avoid invoking initialize_auto_increment(), because the purge thread may already be holding an shared latch on the clustered index root page. Shared latches are not recursive. The additional request would lead to a hang if another thread has started waiting for an exclusive latch.
* | Merge 10.2 into 10.3, except MDEV-25682Marko Mäkelä2021-05-181-2/+6
|\ \ | |/
| * MDEV-25594: Assertion failure in DeadlockChecker::check_and_resolve()Marko Mäkelä2021-05-181-2/+6
| | | | | | | | | | | | | | | | | | | | | | ha_innobase::index_read(): If an autocommit non-locking transaction was already started, refuse to access a SPATIAL INDEX. Once a non-locking autocommit transaction has started, it must remain in that mode (not acquire any locks). This should fix one cause of the assertion failure that would occur in DeadlockChecker::check_and_resolve() under heavy load, presumably due to concurrent execution of trx_commit_in_memory().
* | Merge branch bb-10.2-release into bb-10.3-releaseNikita Malyavin2021-05-042-5/+50
|\ \ | |/
| * MDEV-25536 InnoDB: Failing assertion: sym_node->table != NULL in ↵Thirunarayanan Balathandayuthapani2021-04-301-1/+2
| | | | | | | | | | | | | | | | | | pars_retrieve_table_def InnoDB tries to fetch the deleted doc ids for discarded tablespace. In i_s_fts_deleted_generic_fill(), InnoDB needs to check whether the table is discarded or not before fetching deleted doc ids.
| * MDEV-22928 InnoDB fails to fetch index type when index mismatch happensThirunarayanan Balathandayuthapani2021-04-271-4/+10
| | | | | | | | | | | | InnoDB fails to fetch the index type when innodb dictionary doesn't match with frm. InnoDB should return corrupted if it can't find the index in ha_innobase::index_type().
| * revive innodb_debug_syncNikita Malyavin2021-04-271-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-24758 heap-use-after-poison in innobase_add_instant_try/rec_copyMarko Mäkelä2021-04-261-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a backport of commit fd9ca2a742abe2e91b2b77e70915dec7bd3cd7e1 (MDEV-23295) and commit 9a156e1a23046ba3e37bdb1e4e1ad887d3f5829b (MDEV-23345) to 10.3. An instant ADD/DROP/reorder column could create a dummy table object with the wrong ROW_FORMAT when innodb_default_row_format was changed between CREATE TABLE and ALTER TABLE. prepare_inplace_alter_table_dict(): If we had promised that ALGORITHM=INPLACE is supported, we must preserve the ROW_FORMAT. The rest of the changes are related to adding Alter_inplace_info::inplace_supported to cache the return value of handler::check_if_supported_inplace_alter().
* | Merge 10.2 into 10.3Marko Mäkelä2021-04-241-17/+15
|\ \ | |/ | | | | except commit 1288dfffe77a99d6c5906d12010a1677ee149308
| * MDEV-23026/MDEV-25474 fixup: Assertion ib_table->stat_initializedMarko Mäkelä2021-04-241-11/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is possible that an object that was originally created by open_purge_table() will remain cached and reused for SQL execution. Our previous fix wrongly assumed that ha_innobase::open() would always be called before SQL execution starts. Therefore, we must invoke dict_stats_init() in ha_innobase::info_low() instead of only doing it in ha_innobase::open(). Note: Concurrent execution of dict_stats_init() on the same table is possible, but it also was possible between two calls to ha_innobase::open(), with no ill effects observed. This should fix the assertion failure on stat_initialized. A possibly easy way to reproduce it would have been to run the server with innodb_force_recovery=2 (disable the purge of history), update a table so that an indexed virtual column will be affected, and finally restart the server normally (purge enabled), to observe a crash when the table is accessed from SQL. The problem was first observed and this fix verified by Elena Stepanova. Also Thirunarayanan Balathandayuthapani repeated the problem.
| * MDEV-23455 Hangs + Sig11 in unknown location(s) due to single complex FK queryAleksey Midenkov2021-04-231-3/+4
| | | | | | | | | | | | | | | | Buffer overflow in ib_push_warning() fixed by using vsnprintf(). InnoDB parser was obsoleted by MDEV-16417. Thanks to Nikita Malyavin for review and suggestion.
* | Merge 10.2 into 10.3Marko Mäkelä2021-04-221-4/+8
|\ \ | |/
| * MDEV-25474 Background thread returns uninitialized statisticsbb-10.2-MDEV-25474Thirunarayanan Balathandayuthapani2021-04-211-2/+6
| | | | | | | | | | | | | | | | | | to mysql interpreter InnoDB returns uninitialized statistics to mysql interpreter when background thread is opening the table. So it leads to assertion failure. In that case, InnoDB avoid sending innodb statistics information to mysql interpreter.
* | Merge 10.2 into 10.3Marko Mäkelä2021-04-211-2/+4
|\ \ | |/
| * MDEV-23026 purge fails with assert !rw_lock_own_flagged(lock, ↵st-10.2-MDEV-23026Thirunarayanan Balathandayuthapani2021-04-151-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RW_LOCK_FLAG_X | RW_LOCK_FLAG_S) InnoDB purge thread locks the root page of clustered index while accessing the undo log records and later same thread tries to open the table, initialize statistics and tries to lock the clustered index root page while doing virtual column computation. Solution: ========= InnoDB should prevent statistics initialization when the table is being opened by purge thread
* | Merge 10.2 into 10.3Marko Mäkelä2021-04-131-23/+61
|\ \ | |/
| * MDEV-24971 InnoDB access freed virtual column after rollback of secondary indexst-10.2-MDEV-24971Thirunarayanan Balathandayuthapani2021-04-131-2/+1
| | | | | | | | | | - Fixing post-fix failure. In clean_new_vcol_index(), InnoDB has the wrong offset to store the virtual column
| * MDEV-24971 InnoDB access freed virtual column after rollback of secondary indexThirunarayanan Balathandayuthapani2021-04-121-19/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: ======== InnoDB fails to clean the index stub if it fails to add the virtual index which contains new virtual column. But it clears the newly virtual column from index in clear_added_indexes() during inplace_alter_table. On commit, InnoDB evicts and reload the table. In case of rollback, it doesn't happen. InnoDB clears the ABORTED index while opening the table or doing the DDL. In the mean time, InnoDB can access the dropped virtual index columns while creating prebuilt or rollback of concurrent DML. Solution: ========== (1) InnoDB should maintain newly added virtual column while rollbacking the newly added virtual index. (2) InnoDB must not defer the index removal if the alter table is executed with LOCK=EXCLUSIVE. (3) For LOCK=SHARED, InnoDB should check whether the table has any other transaction lock other than alter transaction before deferring the index stub. Replaced has_new_v_col with dict_add_vcol_info in dict_index_t to indicate whether the index has any new virtual column. dict_index_t::has_new_v_col(): Returns whether the index has newly added virtual column, it doesn't say which columns are newly added virtual column ha_innobase_inplace_ctx::is_new_vcol(): Return whether the given column is added as a part of the current alter. ha_innobase_inplace_ctx::clean_new_vcol_index(): Copy the newly added virtual column to new_vcol_info in dict_index_t. Replace the column in the index fields with virtual column stored in new_vcol_info. dict_index_t::assign_new_v_col(): Store the number of virtual column added in index as a part of alter table. dict_index_t::get_n_new_vcol(): Get the number of newly added virtual column dict_index_t::assign_drop_v_col(): Allocate the memory for adding new virtual column in new_vcol_info. dict_index_t::add_drop_v_col(): Add the newly added virtual column in new_vcol_info. dict_table_t::has_lock_for_other_trx(): Whether the table has any other transaction lock than given transaction. row_merge_drop_indexes(): Add parameter alter_trx and check whether the table has any other lock than alter transaction.
* | Merge 10.2 into 10.3Marko Mäkelä2021-04-092-3/+8
|\ \ | |/
| * MDEV-25295 Aborted FTS_DOC_ID_INDEX considered as existing FTS_DOC_ID_INDEX ↵bb-10.2-MDEV-25295Thirunarayanan Balathandayuthapani2021-04-061-2/+4
| | | | | | | | | | | | | | | | | | during DDL InnoDB should skip the dropped aborted FTS_DOC_ID_INDEX while checking the existing FTS_DOC_ID_INDEX in the table. InnoDB should able to create new FTS_DOC_ID_INDEX if the fulltext index is being added for the first time.
| * MDEV-25047: SIGSEGV in mach_read_from_n_little_endianbb-10.2-MDEV-25047mkaruza2021-04-011-1/+4
| | | | | | | | | | | | | | Virtual column fields are not found in prebuilt data type, so we should match InnoDB fields with `get_innobase_type_from_mysql_type` method. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
* | Merge 10.2 into 10.3Marko Mäkelä2021-03-311-16/+21
|\ \ | |/
| * MDEV-24923 : Port selected Galera conflict resolution changes from 10.6Jan Lindström2021-03-301-11/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add condition on trx->state == TRX_STATE_COMMITTED_IN_MEMORY in order to avoid unnecessary work. If a transaction has already been committed or rolled back, it will release its locks in lock_release() and let the waiting thread(s) continue execution. Let BF wait on lock_rec_has_to_wait and if necessary other BF is replayed. wsrep_trx_order_before If BF is not even replicated yet then they are ordered correctly. bg_wsrep_kill_trx Make sure victim_trx is found and check also its state. If state is TRX_STATE_COMMITTED_IN_MEMORY transaction is already committed or rolled back and will release it locks soon. wsrep_assert_no_bf_bf_wait Transaction requesting new record lock should be TRX_STATE_ACTIVE Conflicting transaction can be in states TRX_STATE_ACTIVE, TRX_STATE_COMMITTED_IN_MEMORY or in TRX_STATE_PREPARED. If conflicting transaction is already committed in memory or prepared we should wait. When transaction is committed in memory we held trx mutex, but not lock_sys->mutex. Therefore, we could end here before transaction has time to do lock_release() that is protected with lock_sys->mutex. lock_rec_has_to_wait We very well can let bf to wait normally as other BF will be replayed in case of conflict. For debug builds we will do additional sanity checks to catch unsupported bf wait if any. wsrep_kill_victim Check is victim already in TRX_STATE_COMMITTED_IN_MEMORY state and if it is we can return. lock_rec_dequeue_from_page lock_rec_unlock Remove unnecessary wsrep_assert_no_bf_bf_wait function calls. We can very well let BF wait here.
* | Merge 10.2 into 10.3Marko Mäkelä2021-03-272-23/+9
|\ \ | |/
| * MDEV-23076 Misleading "InnoDB: using atomic writes"Marko Mäkelä2021-03-222-18/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-221-6/+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.)
* | Merge 10.2 into 10.3Marko Mäkelä2021-03-181-157/+236
|\ \ | |/
| * MDEV-10682 Race condition between ANALYZE and STATS_AUTO_RECALCMarko Mäkelä2021-03-181-0/+14
| | | | | | | | | | | | | | | | | | | | | | ha_innobase::info_low(): While collecting statistics for ANALYZE TABLE, ensure that dict_stats_process_entry_from_recalc_pool() is not executing on the same table. We observed result differences for the test innodb.innodb_stats because dict_stats_empty_index() was being invoked by the background statistics calculation while ha_innobase::analyze() was executing dict_stats_analyze_index_level().
| * MDEV-24978 : SIGABRT in __libc_messageJan Lindström2021-03-151-21/+42
| | | | | | | | | | | | Keyvalue can be longer than REC_VERSION_56_MAX_INDEX_COL_LEN and this leads out-of-array reference. Use dynamic memory allocation using actual max length of key value.
| * MDEV-24853: Duplicate key generated during cluster configuration changeJulius Goryavsky2021-03-081-131/+177
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Incorrect processing of an auto-incrementing field in the WSREP-related code during applying transactions results in a duplicate key being created. This is due to the fact that at the beginning of the write_row() and update_row() functions, the values of the auto-increment parameters are used, which are read from the parameters of the current thread, but further along the code other values are used, which are read from global variables (when applying a transaction). This can happen when the cluster configuration has changed while applying a transaction (for example in the high_priority_service mode for Galera 4). Further during IST processing duplicating key is detected, and processing of the DB_DUPLICATE_KEY return code (inside innodb, in the write_row() handler) results in a call to the wsrep_thd_self_abort() function.
* | MDEV-25106 Deprecation warning for innodb_checksum_algorithm=none,innodb,...Marko Mäkelä2021-03-111-3/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MDEV-25105 (commit 7a4fbb55b02b449a135fe935f624422eaacfdd7c) in MariaDB 10.6 will refuse the innodb_checksum_algorithm values none, innodb, strict_none, strict_innodb. We will issue a deprecation warning if innodb_checksum_algorithm is set to any of these non-default unsafe values. innodb_checksum_algorithm=crc32 was made the default in MySQL 5.7 and MariaDB Server 10.2, and given that older versions of the server have reached their end of life, there is no valid reason to use anything else than innodb_checksum_algorithm=crc32 or innodb_checksum_algorithm=strict_crc32 in MariaDB 10.3. Reviewed by: Sergei Golubchik
* | Merge 10.2 into 10.3Marko Mäkelä2021-03-051-14/+18
|\ \ | |/
| * MDEV-25051 Race condition between persistent statistics and RENAME TABLE or ↵Marko Mäkelä2021-03-041-14/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TRUNCATE innobase_rename_table(): Invoke dict_stats_wait_bg_to_stop_using_table() to ensure that dict_stats_update() cannot be accessing the table name that we will be modifying. If we are executing RENAME rather than TRUNCATE, reset the flag at the end so that persistent statistics can be calculated again. The race condition was encountered with ASAN and rr. Sorry, there is no test case, like there is for nothing related to dict_stats_wait_bg_to_stop_using_table(). The entire code is an ugly work-around for the failure of dict_stats_process_entry_from_recalc_pool() to acquire MDL. Note: It appears that an ALTER TABLE that is not rebuilding the table will fail to reset the flag that blocks the processing of statistics.
* | Merge 10.2 into 10.3Marko Mäkelä2021-03-031-2/+3
|\ \ | |/
| * MDEV-24532 Table corruption ER_NO_SUCH_TABLE_IN_ENGINE .. on table with ↵Monty2021-03-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | foreign key When doing a truncate on an Innodb under lock tables, InnoDB would rename the old table to #sql-... and recreate a new 't1' table. The table lock would still be on the #sql-table. When doing ALTER TABLE, Innodb would do the changes on the #sql table (which would disappear on close). When the SQL layer, as part of inline alter table, would close the original t1 table (#sql in InnoDB) and then reopen the t1 table, Innodb would notice that this does not match it's own (old) t1 table and generate an error. Fixed by adding code in truncate table that if we are under lock tables and truncating an InnoDB table, we would close, reopen and lock the table after truncate. This will remove the #sql table and ensure that lock tables is using the new empty table. Reviewer: Marko Mäkelä
* | Merge branch '10.2' into 10.3Sergei Golubchik2021-02-221-0/+34
|\ \ | |/
| * MDEV-24873 : galera.galera_as_slave_ctas MTR failed: Assertion ↵Jan Lindström2021-02-171-1/+1
| | | | | | | | | | | | | | | | `(&(&LOCK_thd_data)->m_mutex)->count > 0 && pthread_equal(pthread_self(), (&(&LOCK_thd_data)->m_mutex)->thread)' failed in sql_class.cc on THD::awake(killed_state) Problem was that thd::awake assumes now that you hold THD::LOCK_thd_data so we need to keep it when we call wsrep_thd_awake from wsrep_abort_transaction.
| * MDEV-24763 ALTER TABLE fails to rename a column in SYS_FIELDSMarko Mäkelä2021-02-121-0/+34
| | | | | | | | | | | | | | | | | | | | innobase_rename_column_try(): When renaming SYS_FIELDS records for secondary indexes, try to use both formats of SYS_FIELDS.POS as keys, in case the PRIMARY KEY includes a column prefix. Without this fix, an ALTER TABLE that renames a column followed by a server restart (or LRU eviction of the table definition from dict_sys) would make the table inaccessible.
* | mergeSergei Golubchik2021-02-021-2/+6
| |
* | Merge branch '10.2' into 10.3Sergei Golubchik2021-02-011-99/+130
|\ \ | |/
| * MDEV-23328 Server hang due to Galera lock conflict resolutionSergei Golubchik2021-01-241-70/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mutex order violation here. 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 To fix the mutex order violation we kill the victim thd asynchronously, from the manager thread
| * cleanup: void hton::abort_transaction()Sergei Golubchik2021-01-241-31/+19
| | | | | | | | | | | | | | and void wsrep_innobase_kill_one_trx() as their return values are never used. Also remove redundant cast and checks that are always true
| * MDEV-24609: innodb_io_capacity can exceed innodb_io_capacity_maxMarko Mäkelä2021-01-191-1/+2
| | | | | | | | | | | | | | | | | | | | | | innodb_io_capacity_update(): When the requested innodb_io_capacity exceeds innodb_io_capacity_max and is more than half the maximum, do not double it for computing innodb_io_capacity_max. This integer arithmetics overflow was introduced in commit 0f32299437a036ddaad04fe14a6ff63d15e3a72b (MDEV-7035). No test case is added, because sizeof(ulong) varies between platforms.
| * MDEV-24491 db_name mismatch happens during virtual column computationThirunarayanan Balathandayuthapani2021-01-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Database name mismatch happens while opening the table for virtual column computation. Because table_name_parse() returns the length of database and table name before converting the filename to table name. This issue is caused by commit 8b0d4cff0760b0a35285c315d82c49631c108baf (MDEV-15855). Fix should be that table_name_parse() should return the length of database and table name after converting the filename to table name. Reviewed-by: Marko Mäkelä
| * MDEV-21478 fixup: Avoid a memory leakMarko Mäkelä2021-01-141-4/+3
| |
| * MDEV-24536 innodb_idle_flush_pct has no effectMarko Mäkelä2021-01-131-6/+21
| | | | | | | | | | | | | | | | | | 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-23536 Race condition between KILL and transaction commitSergei Golubchik2021-01-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Server part: kill_handlerton() was accessing thd->ha_data[] for some other thd, while it could be concurrently modified by its owner thd. protect thd->ha_data[] modifications with a mutex. require this mutex when accessing thd->ha_data[] from kill_handlerton. InnoDB part: on close_connection, detach trx from thd before freeing the trx
View Lorry Controller Status