- 20 May, 2020 9 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Thirunarayanan Balathandayuthapani authored
prepare_inplace_alter_table_dict(): In the error handling, relax a debug assertion for the case that we did not execute dict_stats_wait_bg_to_stop_using_table() yet.
-
Alexander Barkov authored
Problem: When handling a query like this: VALUES ('') UNION SELECT _utf16 0x0020 COLLATE utf16_bin; Type_handler_string_result::Item_hybrid_func_fix_attributes() tried to apply character set conversion Item_type_holder, which causes a crash on DBUG_ASSERT(0) inside Item_type_holder::val_str(). Fix: Overriding Item_type_holder's methods to avoid this, as follows: bool const_item() const { return false; } bool is_expensive() { return true; }
-
Marko Mäkelä authored
For no good reason, innodb_encryption_threads was limited to 4,294,967,295. Expectedly, the server would crash if such an insane value was specified. Let us limit the maximum to 255. The encryption threads are not doing much useful work. They are basically only dirtying pages by performing dummy writes via the redo log. The encryption key rotation or the in-place addition or removal of encryption will take place in the page cleaner. In a quick test on a 20-core CPU (40 threads in total), the sweet spot on an otherwise idle server seemed to be innodb_encryption_threads=16 for the test encryption.encrypt_and_grep. The new limit 255 should be more than enough for even bigger servers.
-
Yury Kurlykov authored
fts_indexes field in fts_update_t never used. So replace fts_update_t with doc_id_t in the code
-
Marko Mäkelä authored
-
Jan Lindström authored
MDEV-18838 : galera.galera_toi_truncate: Test failure: mysqltest: query 'reap' succeeded - should have failed with errno 1213 Test cleanup.
-
- 19 May, 2020 21 commits
-
-
Andrei Elkin authored
This is a new test from upstream that did not expect the correct value of the command slot of the Dump thread when the latter gets killed. The test is made to expect "Killed" string as the command in show-processlist as it is supposed to when a thread gets killed.
-
Marko Mäkelä authored
-
Rasmus Johansson authored
-
Rasmus Johansson authored
-
Rasmus Johansson authored
-
Rasmus Johansson authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
dict_index_remove_from_cache_low(): Add a missing #ifdef around dict_index_t::freed().
-
Marko Mäkelä authored
This is a regression due to MDEV-16376 commit 8dc70c86. To make dict_index_t::detach_columns() idempotent, we cleared dict_index_t::n_fields. But, this could cause trouble with purge after a secondary index creation failed (not even involving virtual columns). A better way is to clear the dict_field_t::col pointers that point to virtual columns that are being freed due to aborting index creation on an index that depends on a virtual column. Note: the v_cols[] of an existing dict_table_t object will never be modified. If any virtual columns are added or removed, ha_innobase::commit_inplace_alter_table() would invoke dict_table_remove_from_cache() and reload the table to dict_sys. Index creation is a special case where the dict_index_t points to virtual columns that do not yet exist in dict_table_t.
-
Marko Mäkelä authored
This is a regression due to the cleanup commit 12f804ac. row_sel_open_pcur(): Remove the unnecessary parameter. It suffices for us to acquire the adaptive hash index latch only when btr_search_guess_on_hash() is called by btr_cur_search_to_nth_level_func(), in btr_pcur_open_with_no_init(). This code seems to be a relic from the times when there was only one btr_search_latch, which was held in shared mode for longer periods of time. Another relic of that era was removed in commit e5980bf1. This clean-up was missed when the btr_search_latch was split in mysql/mysql-server/commit@ab17ab91ce18a47bb6c5c49e4dc0505ad488a448 (MySQL 5.7.8).
-
Monty authored
This is because it breaks code that is using extern "C" when including my_atomic, which is the case with ha_s3.cc
-
Rasmus Johansson authored
-
Monty authored
-
Alexander Barkov authored
Removing a wrong DBUG_ASSERT: When Item_param gets "unfixed" in cleanup(), its "fixed" gets assigned to false, while item_item keeps the value. So the assert was wrong. Perhaps, instead of removing the assert, it was possible to reset item_type to NO_VALUE in cleanup. But this is not very important: it's implemented in 10.4 in a better way: Item_param::is_fixed() always returns true and it does not need to be "unfixed".
-
Alexander Barkov authored
The fix for MDEV-21995 earlier fixed MDEV-22610. Adding tests only.
-
Vlad Lesin authored
error is logged The fix is to set flag in ib::error::~error() and check it in mariabackup. ib::error::error() is replaced with ib::warn::warn() in AIO::linux_create_io_ctx() because of two reasons: 1) if we leave it as is, then mariabackup MTR tests will fail with --mem option, because Linux AIO can not be used on tmpfs, 2) when Linux AIO can not be initialized, InnoDB falls back to simulated AIO, so such sutiation is not fatal error, it should be treated as warning.
-
Alexander Barkov authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
lock_table_locks_lookup(): Relax the assertion. Locks must not exist while online secondary index creation is in progress. However, if CREATE UNIQUE INDEX has not been committed yet, but the index creation has been completed, concurrent DML transactions may acquire record locks on the index. Furthermore, such concurrent DML may cause duplicate key violation, causing the DDL operation to be rolled back. After that, the online_status may be ONLINE_INDEX_ABORTED or ONLINE_INDEX_ABORTED_DROPPED. So, the debug assertion may only forbid the state ONLINE_INDEX_CREATION.
-
Alexander Barkov authored
1. Code simplification: Item_default_value handled all these values: a. DEFAULT(field) b. DEFAULT c. IGNORE and had various conditions to distinguish (a) from (b) and from (c). Introducing a new abstract class Item_contextually_typed_value_specification, to handle (b) and (c), so the hierarchy now looks as follows: Item Item_result_field Item_ident Item_field Item_default_value - DEFAULT(field) Item_contextually_typed_value_specification Item_default_specification - DEFAULT Item_ignore_specification - IGNORE 2. Introducing a new virtual method is_evaluable_expression() to determine if an Item is: - a normal expression, so its val_xxx()/get_date() methods can be called - or a just an expression substitute, whose value methods cannot be called. 3. Disallowing Items that are not evalualble expressions in table value constructors.
-
Monty authored
MDEV-18457 Assertion `(bitmap->map + (bitmap->full_head_size/6*6)) <= full_head_end failed The problem was that full_head_size was not calculated correctly in the case when insert_order was inforced, which is the case for SHOW commands.
-
- 18 May, 2020 10 commits
-
-
Vladislav Vaintroub authored
TIME_ZONE_ID_UNKNOWN return code from GetDynamicTimeZoneInformation() does not mean failure. It only means, daylight saving dates in the returned strct are not valid. TIME_ZONE_ID_INVALID means failure, in this case "unknown" should be returned
-
Andrei Elkin authored
The assert was caused by early cleanup of a user variable participant in BINLOG @var,@var where it plays twice. That was unexpected by the base code to clear its value prematurely. Fixed with relocating the user var destruction after operations with its value is over.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
In the merge 9e6e4355 we made Atomic_counter a more generic wrapper of std::atomic so that dict_index_t would support the implicit assignment operator. It is better to revert the changes to Atomic_counter and instead introduce Atomic_relaxed as a generic wrapper to std::atomic. Unlike Atomic_counter, we will not define operator++, operator+= or similar, because we want to make the operations more explicit in the users of Atomic_wrapper, because unlike loads and stores, atomic read-modify-write operations always incur some overhead.
-
Jan Lindström authored
Enable tests with additional galera output to find out actual reason for test failures.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
In commit ad6171b9 (MDEV-22456) we removed the acquisition of the adaptive hash index latch from the caller of btr_search_update_hash_ref(). The tests innodb.innodb_buffer_pool_resize_with_chunks and innodb.innodb_buffer_pool_resize would occasionally fail starting with 10.3, due to MDEV-12288 causing more purge activity during the test. btr_search_update_hash_ref(): After acquiring the adaptive hash index latch, check that the adaptive hash index is still enabled on the page.
-
Julius Goryavsky authored
The problem is caused by the operation of netcat streamer and does not appear on systems where socat is installed. We need to add the "-N" option for netcat to call shutdown() on the socket when receiving EOF from STDIN.
-
Julius Goryavsky authored
The problem is caused by the operation of netcat streamer and does not appear on systems where socat is installed. We need to add the "-N" option for netcat to call shutdown() on the socket when receiving EOF from STDIN.
-