- 11 Nov, 2021 2 commits
-
-
Vladislav Vaintroub authored
Upon investigation, decided this to be a compiler bug (happens with new compiler, on code that did not change for the last 15 years) Fixed by de-optimizing single function remove_key(), using MSVC pragma
-
Brandon Nesterenko authored
MDEV-26991: CURRENT_TEST: main.mysql_binary_zero_insert 'grep' is not recognized as an internal or external command, operable program or batch file. Removed grep from mysqldump command stream and instead, extend the search_file pattern to search for rows containing binary zeros instead of any occurance of '00' in the input
-
- 09 Nov, 2021 5 commits
-
-
Marko Mäkelä authored
This fixes up commit d22c8cae
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Daniel Black authored
The previous threads locked need to be released too. This occurs if the initialization of any of the non-first mutex/conditition variables errors occurs.
-
ryancaicse authored
Fix a bug of unreleased lock ctrl_mutex in the method create_worker_threads
-
- 08 Nov, 2021 3 commits
-
-
Daniel Bartholomew authored
-
Alexey Bychko authored
added summary/description per package.
-
Alexander Barkov authored
-
- 05 Nov, 2021 1 commit
-
-
Andrei Elkin authored
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.
-
- 04 Nov, 2021 1 commit
-
-
Vladislav Vaintroub authored
-
- 03 Nov, 2021 1 commit
-
-
Sergei Krivonos authored
This reverts commit 5d6f3ceb.
-
- 02 Nov, 2021 3 commits
-
-
Aleksey Midenkov authored
When restoring lastinx last_key.keyinfo must be updated as well. The good example is in _ma_check_index(). The point of failure is extra(HA_EXTRA_NO_KEYREAD) in ha_maria::get_auto_increment(): 1. extra(HA_EXTRA_KEYREAD) saves lastinx; 2. maria_rkey() changes index, so the lastinx and last_key.keyinfo; 3. extra(HA_EXTRA_NO_KEYREAD) restores lastinx but not last_key.keyinfo. So we have discrepancy between lastinx and last_key.keyinfo after 3.
-
Jan Lindström authored
Use better error message when KILL fails even in case TOI fails.
-
Alexander Barkov authored
my_copy_fix_mb() passed MIN(src_length,dst_length) to my_append_fix_badly_formed_tail(). It could break a multi-byte character in the middle, which put the question mark to the destination. Fixing the code to pass the true src_length to my_append_fix_badly_formed_tail().
-
- 01 Nov, 2021 2 commits
-
-
Jan Lindström authored
* Fix error handling NULL-pointer reference * Add mtr-suppression on galera_ssl_upgrade
-
Marko Mäkelä authored
There is a server startup option --gdb a.k.a. --debug-gdb that requests signals to be set for more convenient debugging. Most notably, SIGINT (ctrl-c) will not be ignored, and you will be able to interrupt the execution of the server while GDB is attached to it. When we are debugging, the signal handlers that would normally display a terse stack trace are useless. When we are debugging with rr, the signal handlers may interfere with a SIGKILL that could be sent to the process by the environment, and ruin the rr replay trace, due to a Linux kernel bug https://lkml.org/lkml/2021/10/31/311 To be able to diagnose bugs in kill+restart tests, we may really need both a trace before the SIGKILL and a trace of the failure after a subsequent server startup. So, we had better avoid hitting the problem by simply not installing those signal handlers.
-
- 30 Oct, 2021 2 commits
-
-
Sergei Krivonos authored
-
Sergei Krivonos authored
-
- 29 Oct, 2021 3 commits
-
-
Alexander Barkov authored
MDEV-24901 SIGSEGV in fts_get_table_name, SIGSEGV in ib_vector_size, SIGSEGV in row_merge_fts_doc_tokenize, stack smashing strmake() puts one extra 0x00 byte at the end of the string. The code in my_strnxfrm_tis620[_nopad] did not take this into account, so in the reported scenario the 0x00 byte was put outside of a stack variable, which made ASAN crash. This problem is already fixed in in MySQL: commit 19bd66fe43c41f0bde5f36bc6b455a46693069fb Author: bin.x.su@oracle.com <> Date: Fri Apr 4 11:35:27 2014 +0800 But the fix does not seem to be correct, as it breaks when finds a zero byte in the source string. Using memcpy() instead of strmake(). - Unlike strmake(), memcpy() it does not write beyond the destination size passed. - Unlike the MySQL fix, memcpy() does not break on the first 0x00 byte found in the source string.
-
sjaakola authored
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>
-
Jan Lindström authored
Revert "MDEV-23328 Server hang due to Galera lock conflict resolution" This reverts commit 29bbcac0.
-
- 28 Oct, 2021 7 commits
-
-
Andrei Elkin authored
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.
-
Oleksandr Byelkin authored
-
Alice Sherepa authored
rpl_get_master_version_and_clock and rpl_row_big_table_id tests are slow, so let's not run them under valgrind
-
Oleksandr Byelkin authored
-
Vladislav Vaintroub authored
Those messages don't indicate errors, they should be normal warnings.
-
Marko Mäkelä authored
The InnoDB changes in MySQL 5.7.36 that were applicable to MariaDB were covered by MDEV-26864, MDEV-26865, MDEV-26866.
-
Nikita Malyavin authored
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.
-
- 27 Oct, 2021 3 commits
-
-
Sergei Petrunia authored
ha_rocksdb.h:459:15: warning: 'table_type' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
-
Alexander Barkov authored
The assert inside String::copy() prevents copying from from "str" if its own String::Ptr also points to the same memory. The idea of the assert is that copy() performs memory reallocation, and this reallocation can free (and thus invalidate) the memory pointed by Ptr, which can lead to further copying from a freed memory. The assert was incomplete: copy() can free the memory pointed by its Ptr only if String::alloced is true! If the String is not alloced, it is still safe to copy even from the location pointed by Ptr. This scenario demonstrates a safe copy(): const char *tmp= "123"; String str1(tmp, 3); String str2(tmp, 3); // This statement is safe: str2.copy(str1->ptr(), str1->length(), str1->charset(), cs_to, &errors); Inside the copy() the parameter "str" is equal to String::Ptr in this example. But it's still ok to reallocate the memory for str2, because str2 was a constant before the copy() call. Thus reallocation does not make the memory pointed by str1->ptr() invalid. Adjusting the assert condition to allow copying for constant strings.
-
Marko Mäkelä authored
-
- 26 Oct, 2021 6 commits
-
-
Diego Dupin authored
Take into account client capabilities.
-
Oleksandr Byelkin authored
-
Oleksandr Byelkin authored
-
Vladislav Vaintroub authored
Sometimes, although not often, it would timeout after 3 minutes.
-
Vladislav Vaintroub authored
Happens with Innodb engine. Move unlock_locked_table() past drop_open_table(), and rollback current statement, so that we can actually unlock the table. Anything else results in assertions, in drop, or unlock, or in close_table.
-
Thirunarayanan Balathandayuthapani authored
MDEV-25702(commit 696de6d0) should've closed the fts table further. This patch closes the table after finishing the bulk insert operation.
-
- 25 Oct, 2021 1 commit
-
-
Alexey Botchkov authored
DBUG_ASSERT removed as the AUTO INCREMENT can actually be 0 when the SET insert_id= 0; was done.
-