summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
| | | | * | | | | | | MDEV-25803 Inplace ALTER breaks MyISAM/Aria table when order of keys is changedAleksey Midenkov2021-11-038-12/+114
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mysql_prepare_create_table() does my_qsort(sort_keys) on key info. This sorting is indeterministic: a table is created with one order and inplace alter may overwrite frm with another order. Since inplace alter does nothing about key info for MyISAM/Aria storage engines this results in discrepancy between frm and storage engine key definitions. The fix avoids the sorting of keys when no new keys added by ALTER (and this is ok for MyISAM/Aria since it cannot add new keys inplace). There is a case when implicit primary key may be changed when removing NOT NULL from the part of unique key. In that case we update modified_primary_key which is then used to not skip key sorting. According to is_candidate_key() there is no other cases when primary key may be changed implicitly. Notes: mi_keydef_write()/mi_keyseg_write() are used only in mi_create(). They should be used in ha_inplace_alter_table() as well. Aria corruption detection is unimplemented: maria_check_definition() is never used! MySQL 8.0 has this bug as well as of 8.0.26.
| | * | | | | | | | | Merge branch '10.6' into bb-10.6-releaseOleksandr Byelkin2021-11-0821-336/+105
| | |\ \ \ \ \ \ \ \ \
| | | * | | | | | | | | bump the VERSIONDaniel Bartholomew2021-11-081-1/+1
| | | | | | | | | | | |
| * | | | | | | | | | | Merge branch '10.7' into bb-10.7-releaseOleksandr Byelkin2021-11-0826-343/+199
| |\ \ \ \ \ \ \ \ \ \ \
| | * | | | | | | | | | | bump the VERSIONbb-10.7-bumpversionDaniel Bartholomew2021-11-081-1/+1
| | | | | | | | | | | | |
| * | | | | | | | | | | | Merge branch '10.6' into 10.7mariadb-10.7.1Oleksandr Byelkin2021-11-059-50/+1210
| |\ \ \ \ \ \ \ \ \ \ \ \ | | | |/ / / / / / / / / / | | |/| | | | | | | | | |
| | * | | | | | | | | | | Merge branch '10.5' into 10.6mariadb-10.6.5Oleksandr Byelkin2021-11-059-50/+1210
| | |\ \ \ \ \ \ \ \ \ \ \ | | | | |_|/ / / / / / / / | | | |/| | | | | | | | |
| | | * | | | | | | | | | Merge branch '10.4' into 10.5mariadb-10.5.13Oleksandr Byelkin2021-11-059-50/+1210
| | | |\ \ \ \ \ \ \ \ \ \ | | | | | |_|_|/ / / / / / | | | | |/| | | | | | | |
| | | | * | | | | | | | | Merge branch '10.3' into 10.4mariadb-10.4.22Oleksandr Byelkin2021-11-059-50/+1210
| | | | |\ \ \ \ \ \ \ \ \ | | | | | | |_|_|_|_|/ / / | | | | | |/| | | | | | |
| | | | | * | | | | | | | Merge branch '10.2' into 10.3mariadb-10.3.32Oleksandr Byelkin2021-11-059-50/+1210
| | | | | |\ \ \ \ \ \ \ \ | | | | | | | |_|_|_|_|_|/ | | | | | | |/| | | | | |
| | | | | | * | | | | | | MDEV-26833 Missed statement rollback in case transaction drops or create ↵mariadb-10.2.41Andrei Elkin2021-11-059-51/+1211
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | temporary table When transaction creates or drops temporary tables and afterward its statement faces an error even the transactional table statement's cached ROW format events get involved into binlog and are visible after the transaction's commit. Fixed with proper analysis of whether the errored-out statement needs to be rolled back in binlog. For instance a fact of already cached CREATE or DROP for temporary tables by previous statements alone does not cause to retain the being errored-out statement events in the cache. Conversely, if the statement creates or drops a temporary table itself it can't be rolled back - this rule remains.
| * | | | | | | | | | | | Merge 10.6 into 10.7Marko Mäkelä2021-11-053-1/+3
| |\ \ \ \ \ \ \ \ \ \ \ \ | | |/ / / / / / / / / / /
| | * | | | | | | | | | | MDEV-26826 fixup: ROW_FORMAT=COMPRESSED may corrupt buf_pool.page_hashMarko Mäkelä2021-11-053-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit c091a0bc8da87045f10bfc96618ed7194768fa2d we removed the use of the HASH_ macros for inserting into buf_pool.page_hash, or accessing buf_page_t::hash. However, the binary buddy allocator for block->page.zip.data would still use the HASH_ macros. HASH_INSERT and not HASH_DELETE would reset the next-block pointer to the null pointer. Our replacement of HASH_DELETE() will reset the next-block pointer, and the replacement of HASH_INSERT() assumes that the pointer is the null pointer. buf_LRU_block_free_non_file_page(): Assert that the next-block pointer is the null pointer. buf_buddy_block_free(): Reset the pointer before invoking buf_LRU_block_free_non_file_page(). Without this, the added assertion would fail in the test encryption.innochecksum.
| * | | | | | | | | | | | Merge branch '10.6' into 10.7Sergei Golubchik2021-11-051-1/+1
| |\ \ \ \ \ \ \ \ \ \ \ \ | | |/ / / / / / / / / / /
| | * | | | | | | | | | | Merge branch '10.5' into 10.6Sergei Golubchik2021-11-051-1/+1
| | |\ \ \ \ \ \ \ \ \ \ \ | | | |/ / / / / / / / / /
| | | * | | | | | | | | | change pcre2 download urlSergei Golubchik2021-11-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | old ftp.pcre.org is apparently down, www.pcre.org says to use github as the primary download location
| | * | | | | | | | | | | columnstoreSergei Golubchik2021-11-041-0/+0
| | | | | | | | | | | | |
| * | | | | | | | | | | | columnstoreSergei Golubchik2021-11-041-0/+0
| | | | | | | | | | | | |
| * | | | | | | | | | | | Merge branch '10.6' into 10.7Oleksandr Byelkin2021-11-030-0/+0
| |\ \ \ \ \ \ \ \ \ \ \ \ | | |/ / / / / / / / / / /
| | * | | | | | | | | | | Merge branch '10.5' into 10.6Oleksandr Byelkin2021-11-030-0/+0
| | |\ \ \ \ \ \ \ \ \ \ \ | | | |/ / / / / / / / / /
| | | * | | | | | | | | | Merge branch '10.4' into 10.5Oleksandr Byelkin2021-11-030-0/+0
| | | |\ \ \ \ \ \ \ \ \ \ | | | | |/ / / / / / / / /
| | | | * | | | | | | | | Merge branch '10.3' into 10.4Oleksandr Byelkin2021-11-030-0/+0
| | | | |\ \ \ \ \ \ \ \ \ | | | | | |/ / / / / / / /
| | | | | * | | | | | | | Merge branch '10.2' into 10.3Oleksandr Byelkin2021-11-030-0/+0
| | | | | |\ \ \ \ \ \ \ \ | | | | | | |/ / / / / / /
| | | | | | * | | | | | | MDEV-23328 Server hang due to Galera lock conflict resolutionJan Lindström2021-11-023-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use better error message when KILL fails even in case TOI fails.
| * | | | | | | | | | | | Merge branch '10.6' into 10.7Oleksandr Byelkin2021-11-038-50/+85
| |\ \ \ \ \ \ \ \ \ \ \ \ | | |/ / / / / / / / / / /
| | * | | | | | | | | | | Merge branch '10.5' into 10.6Oleksandr Byelkin2021-11-026-44/+64
| | |\ \ \ \ \ \ \ \ \ \ \ | | | |/ / / / / / / / / /
| | | * | | | | | | | | | Merge branch '10.4' into 10.5Oleksandr Byelkin2021-11-025-38/+52
| | | |\ \ \ \ \ \ \ \ \ \ | | | | |/ / / / / / / / /
| | | | * | | | | | | | | post merge result fixOleksandr Byelkin2021-11-021-0/+3
| | | | | | | | | | | | |
| | | | * | | | | | | | | Merge branch '10.3' into 10.4Oleksandr Byelkin2021-11-025-40/+51
| | | | |\ \ \ \ \ \ \ \ \ | | | | | |/ / / / / / / /
| | | | | * | | | | | | | Merge branch '10.2' into 10.3Oleksandr Byelkin2021-11-020-0/+0
| | | | | |\ \ \ \ \ \ \ \ | | | | | | |/ / / / / / /
| | | | | | * | | | | | | MDEV-23328 Server hang due to Galera lock conflict resolutionJan Lindström2021-11-013-9/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Fix error handling NULL-pointer reference * Add mtr-suppression on galera_ssl_upgrade
| | | | | * | | | | | | | move "bad" test in seperate file with valgrind prohibited (different size of ↵Oleksandr Byelkin2021-11-024-37/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | allocated memory)
| | | | | * | | | | | | | MDEV-23328 Server hang due to Galera lock conflict resolutionJan Lindström2021-11-025-15/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Fix error handling NULL-pointer reference * Add mtr-suppression on galera_ssl_upgrade
| | | | * | | | | | | | | Fix mutex order according to a new sequence.Oleksandr Byelkin2021-11-021-1/+1
| | | | | | | | | | | | |
| | | | * | | | | | | | | MDEV-23328 Server hang due to Galera lock conflict resolutionJan Lindström2021-11-023-9/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Fix error handling NULL-pointer reference * Add mtr-suppression on galera_ssl_upgrade
| | | * | | | | | | | | | MDEV-23328 Server hang due to Galera lock conflict resolutionJan Lindström2021-11-023-9/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Fix error handling NULL-pointer reference * Add mtr-suppression on galera_ssl_upgrade
| | * | | | | | | | | | | MDEV-26674 workaround for mariadb-backupMarko Mäkelä2021-11-022-6/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is follow-up to commit 1193a793c40b806c6f1f007bbd87f4d9a73e686d. We will set innodb_use_native_aio=OFF by default also in mariadb-backup when running on a potentially affected kernel.
| * | | | | | | | | | | | Merge branch '10.6' into 10.7Oleksandr Byelkin2021-10-3124-80/+125
| |\ \ \ \ \ \ \ \ \ \ \ \ | | |/ / / / / / / / / / /
| | * | | | | | | | | | | Merge branch '10.5' into 10.6Oleksandr Byelkin2021-10-300-0/+0
| | |\ \ \ \ \ \ \ \ \ \ \ | | | |/ / / / / / / / / /
| | | * | | | | | | | | | Merge branch '10.4' into 10.5Oleksandr Byelkin2021-10-300-0/+0
| | | |\ \ \ \ \ \ \ \ \ \ | | | | |/ / / / / / / / /
| | | | * | | | | | | | | Merge branch '10.3' into 10.4Oleksandr Byelkin2021-10-290-0/+0
| | | | |\ \ \ \ \ \ \ \ \ | | | | | |/ / / / / / / /
| | | | | * | | | | | | | Merge branch '10.2' into 10.3Oleksandr Byelkin2021-10-290-0/+0
| | | | | |\ \ \ \ \ \ \ \ | | | | | | |/ / / / / / /
| | | | | | * | | | | | | MDEV-23328 Server hang due to Galera lock conflict resolutionsjaakola2021-10-2915-203/+417
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-25114: Crash: WSREP: invalid state ROLLED_BACK (FATAL)Jan Lindström2021-10-292-112/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert "MDEV-23328 Server hang due to Galera lock conflict resolution" This reverts commit 29bbcac0ee841faaa68eeb09c86ff825eabbe6b6.
| | | | | * | | | | | | | MDEV-23328 Server hang due to Galera lock conflict resolutionsjaakola2021-10-2915-207/+427
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-25114: Crash: WSREP: invalid state ROLLED_BACK (FATAL)Jan Lindström2021-10-293-111/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert "MDEV-23328 Server hang due to Galera lock conflict resolution" This reverts commit 29bbcac0ee841faaa68eeb09c86ff825eabbe6b6.
| | | | * | | | | | | | | MDEV-23328 Server hang due to Galera lock conflict resolutionsjaakola2021-10-2923-427/+334
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-25114: Crash: WSREP: invalid state ROLLED_BACK (FATAL)Jan Lindström2021-10-2911-191/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert "MDEV-23328 Server hang due to Galera lock conflict resolution" This reverts commit eac8341df4c3c7b98360f4e9498acf393dc055e3.
| | | * | | | | | | | | | MDEV-23328 Server hang due to Galera lock conflict resolutionsjaakola2021-10-2921-409/+317
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-25114: Crash: WSREP: invalid state ROLLED_BACK (FATAL)Jan Lindström2021-10-2910-176/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert "MDEV-23328 Server hang due to Galera lock conflict resolution" This reverts commit eac8341df4c3c7b98360f4e9498acf393dc055e3.
View Lorry Controller Status