- 02 Nov, 2020 16 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
latch_t: Replace with rw_lock_t. Only the InnoDB rw-lock implementation will be instrumented. FIXME: srv_sys should be removed altogether; it is duplicating tpool functionality. fil_crypt_threads_init(): To prevent SAFE_MUTEX warnings, we must not hold fil_system.mutex. fil_close_all_files(): To prevent SAFE_MUTEX warnings for fil_space_destroy_crypt_data(), we must not hold fil_system.mutex while invoking fil_space_free_low() on a detached tablespace. LatchDebug::get_level_name(): Implemented as a static function that references a compile-time constant array of level_names[]. There should be no reason to create a constant std::map of numbers to compile-time string constants.
-
Marko Mäkelä authored
We will default to MUTEXTYPE=sys (using OSTrackMutex) for those ib_mutex_t that have not been replaced yet. The innodb_fatal_semaphore_wait_threshold will only apply to InnoDB rw_lock_t, not any mutexes any more. innodb_sync_debug=ON might still cover ib_mutex_t.
-
Marko Mäkelä authored
To hopefully avoid increasing contention on lock_sys.mutex, let us additionally protect trx->lock.wait_lock with trx->mutex so that lock_wait_suspend_thread() can avoid acquiring lock_sys.mutex and use trx_t::mutex instead.
-
Marko Mäkelä authored
Let us replace os_event_t with mysql_cond_t, and replace the necessary ib_mutex_t with mysql_mutex_t so that they can be used with condition variables. The default ib_mutex_t implementation will use os_event_t. Also, replace polling (os_thread_sleep() or timed waits) with plain mysql_cond_wait() wherever possible. FIXME: Add test coverage of mariabackup --backup --kill-long-queries-timeout FIXME: innodb_fatal_semaphore_wait_threshold no longer works because it used to rely on lock_sys.mutex. The test could be rewritten to rely on an InnoDB rw_lock_t instead. fts_cache_t::lock: Replaced the rw_lock_t with a mutex. The only shared latch user was i_s_fts_index_cache_fill(), for producing content for the view INFORMATION_SCHEMA.INNODB_FT_INDEX_CACHED. fts_cache_t::init_lock: Replaced the rw_lock_t with a mutex. This was only being acquired in exclusive mode.
-
Marko Mäkelä authored
Let us use a single rw_lock_t::wait_mutex and two condition variables wait_cond, wait_cond_ex instead of two os_event_t (which wrap a mutex and condition variable and some other data) sync_array_wait_event(): Implement new waiting rules for rw_lock_t. FIXME: Sometimes, rw_lock_s_lock() hangs here. TODO: Find out what the lock->lock_word is in those cases. Maybe we should treat not only the value 0 but also X_LOCK_HALF_DECR specially.
-
Marko Mäkelä authored
-
Vladislav Vaintroub authored
This will avoid some errors on appveyor, due to outdated SDKs.
-
Nikita Malyavin authored
-
Nikita Malyavin authored
Though this is an error message task, the problem was deep in the `mysql_prepare_create_table` implementation. The problem is described as follows: 1. `append_system_key_parts` was called before `mysql_prepare_create_table`, though key name generation was done close to the latest stage of the latter. 2. We can't move `append_system_key_parts` in the end, because system keys should be appended before some checks done. 3. If the checks from `append_system_key_parts` are moved to the end of `mysql_prepare_create_table`, then some other inappropriate errors are issued. like `ER_DUP_FIELDNAME`. To have key name specified in error message, name generation should be done before the checks, which consequenced in more changes. The final design for key initialization in `mysql_prepare_create_table` follows. The initialization is done in three phases: 1. Calculate a total number of keys created with respect to keys ignored. Allocate KEY* buffer. 2. Generate unique names; calculate a total number of key parts. Make early checks. Allocate KEY_PART_INFO* buffer. 3. Initialize key parts, make the rest of the checks.
-
Nikita Malyavin authored
`ha_heap::clone` was creating a handler by share's handlerton, which is partition handlerton. handler's handlerton should be used instead. Here in particular, HEAP handlerton will be used and it will create ha_heap handler.
-
Nikita Malyavin authored
The bug was fixed by MDEV-22599 bugfix, which changed `Field::cmp` call to `Field::cmp_prefix` in `TABLE::check_period_overlaps`. The trick is that `Field_bit::cmp` apparently calls `Field_bit::cmp_key`, which condiders an argument an actual pointer to data, which isn't correct for `Field_bit`, since it stores data by `bit_ptr`. which is in the beginning of the record, and using `ptr` is incorrect (we use it through `ptr_in_record` call)
-
Nikita Malyavin authored
After Sergei's cleanup this assertion is not actual anymore -- we can't predict if the handler was used for lookup, especially in multi-update scenario. `position(old_data)` is made earlier in `ha_check_overlaps`, therefore it is guaranteed that we compare right refs.
-
Nikita Malyavin authored
The problem here was that ha_check_overlaps internally uses ha_index_read, which in case of fail overwrites table->status. Even though the handlers are different, they share a common table, so the value is anyway spoiled. This is bad, and table->status is badly designed and overweighted by functionality, but nothing can be done with it, since the code related to this logic is ancient and it's impossible to extract it with normal effort. So let's just save and restore the value in ha_update_row before and after the checks. Other operations like INSERT and simple UPDATE are not in risk, since they don't use this table->status approach. DELETE does not do any unique checks, so it's also safe.
-
Nikita Malyavin authored
1. Subtracting table->record[0] from record is UB (non-contiguous buffers) 2. It is very popular to use move_field_offset, which changes Field::ptr, but leaves table->record[0] unchanged. This makes a ptr_in_record result incorrect, since it relies on table->record[0] value. The check ensures the result is within the queried record boundaries.
-
Elena Stepanova authored
-
- 01 Nov, 2020 1 commit
-
-
Oleksandr Byelkin authored
-
- 31 Oct, 2020 1 commit
-
-
Oleksandr Byelkin authored
-
- 30 Oct, 2020 16 commits
-
-
Marko Mäkelä authored
buf_flush_try_neighbors(): Before invoking buf_page_t::ready_for_flush(), check that the freshly looked up buf_pool.page_hash entry actually is a buffer page and not a buf_pool.watch[] sentinel for purge buffering. This race condition was introduced in MDEV-15053 (commit b1ab211d). It is rather hard to hit this bug, because buf_flush_check_neighbors() already checked the condition. The problem exists if buf_pool.watch_set() was invoked for a page in the range after the check in buf_flush_check_neighbor() had been finished.
-
Oleksandr Byelkin authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
Thanks to Varun Gupta for suggesting this. This seems to make main.innodb_ext_key,off more stable.
-
Marko Mäkelä authored
Invoking memcpy() on a NULL pointer is undefined behaviour (even if the length is 0) and gives the compiler permission to assume that the pointer is nonnull. Recent versions of GCC (starting with version 8) are more aggressively optimizing away checks for NULL pointers. This undefined behaviour would cause a SIGSEGV in the test main.func_encrypt on an optimized debug build on GCC 10.2.0.
-
Marko Mäkelä authored
This regression was introduced in commit afc9d00c. This is a partial backport of commit 199863d7 from 10.4.
-
Sergei Golubchik authored
-
Marko Mäkelä authored
-
Varun Gupta authored
MDEV-24033: SIGSEGV in __memcmp_avx2_movbe from queue_insert | SIGSEGV in __memcmp_avx2_movbe from native_compare The issue here was the system variable max_sort_length was being applied to decimals and it was truncating the value for decimals to the number of bytes set by max_sort_length. This was leading to a buffer overflow as the values were written to the buffer without truncation and then we moved the offset to the number of bytes(set by max_sort_length), that are needed for comparison. The fix is to not apply max_sort_length for fixed size types like INT, DECIMALS and only apply max_sort_length for CHAR, VARCHARS, TEXT and BLOBS.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
Also, revert the work-around for the test that was attempted in commit 85613a32. This issue was caught by MemorySanitizer as well as on the Microsoft Windows debug builds, thanks to /MD being used starting with 10.4. The code fix will also be applied to 10.2 because the regression was introduced in commit afc9d00c.
-
Jan Lindström authored
Test itself is not deterministic.
-
Jan Lindström authored
Disable galera_var_replicate_myisam until fixed on 10.4
-
Jan Lindström authored
-
Daniel Black authored
Corrects: 7803601d
-
- 29 Oct, 2020 6 commits
-
-
Oleksandr Byelkin authored
-
Oleksandr Byelkin authored
Use 9 byte (min length packet)
-
Monty authored
This bug was already fixed in a previous commit. Added test case from the MDEV to prove it's fixed.
-
Monty authored
The crash happens because a double free in the case CREATE TABLE fails because there is a conflicting tables on disk. Fixed by ensuring that the double free can't happen.
-
Monty authored
On my system, OpenSuse, I got a compilation error that some arguments to getgrouplist() where not initialized
-
Marko Mäkelä authored
For some reason, in the test main,innodb_ext_key,off we frequently get unexpected EXPLAIN output, in particular on Microsoft Windows debug builders. Let us comment out that EXPLAIN statement for now.
-