- 13 May, 2019 4 commits
-
-
Varun Gupta authored
-
Sergey Vojtovich authored
With MDEV-19384 fixed FTWRL releases HANDLER locks early, which allows concurrent threads to go. Test case may get stuck on FTWRL waiting for LOCK TABLES.
-
Monty authored
-
Monty authored
- Remove warning about aria_control_file - Write to unique test file Other things: - Fixed typo in aria_chk --help
-
- 11 May, 2019 2 commits
-
-
Varun Gupta authored
So to push index condition for each join tab we have calculate the index condition that can be pushed and then remove this index condition from the original condition. This is done through the function make_cond_remainder. The problem is the function make_cond_remainder does not remove index condition when there is an OR operator. Fixed this by making the function make_cond_remainder to keep in mind of the OR operator. Also updated results for multiple test files which were incorrectly updated by the commit e0c1b3f2 code which was supposed to remove the condition present in the index condition was not getting executed when the condition had OR operator, with AND the pushed index condition was getting removed from where. This problem affects all versions starting from 5.5 but this is a performance improvement, so fixing it in 10.4
-
Monty authored
Problem was that SHOW CREATE didn't remove PAGE_CHECKSUM=1
-
- 10 May, 2019 2 commits
-
-
hygonsoc authored
Signed-off-by: hygonsoc <hygonsoc@gmail.com>
-
Daniel Black authored
For a table column `a`, the above expressions logically equate to false in all cases. With this patch the optimizer knows about this and queries like: SELECT * FROM t1 WHERE a!=a no longer need to evaluate a!=a for every row. The same applies if the expression was `a<a`, or `a>a` An `EXPLAIN SELECT COOUNT(*) FROM t1 WHERE a<a` will show: id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE Similarly `NOT (a!=a)` is always true. EXPLAIN SELECT COUNT(*) FROM t1 WHERE not (a!=a); id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Select tables optimized away
-
- 09 May, 2019 2 commits
-
-
Vladislav Vaintroub authored
With MAX_INDEXIES=64(default), key_map=Bitmap<64> is just a wrapper around ulonglong and thus "trivial" (can be bzero-ed, or memcpy-ed, and stays valid still) With MAX_INDEXES=128, key_map = Bitmap<128> is not a "trivial" type anymore. The implementation uses MY_BITMAP, and MY_BITMAP contains pointers which make Bitmap invalid, when it is memcpy-ed/bzero-ed. The problem in 10.4 is that there are many new key_map members, inside TABLE or KEY, and those are often memcopied and bzeroed The fix makes Bitmap "trivial", by inlining most of MY_BITMAP functionality. pointers/heap allocations are not used anymore.
-
Monty authored
-
- 07 May, 2019 1 commit
-
-
Vladislav Vaintroub authored
-
- 06 May, 2019 5 commits
-
-
Igor Babaev authored
Parenthesis around table names and derived tables should be allowed in FROM clauses and some other context as it was in earlier versions. Returned test queries that used such parenthesis in 10.3 to their original form. Adjusted test results accordingly.
-
Monty authored
The deadlock happened between FTWRL under open HANDLER, LOCK TABLE and DROP DATABASE Fixed by reverting the previous fix for handler open in lock_global_read_lock() Fixed the original (wrong) test case in flush_read_lock.test to be repeatable.
-
Vladislav Vaintroub authored
Windows does atomic writes, as long as they are aligned and multiple of sector size. this is documented in MSDN. Fix innodb.doublewrite test to always use doublewrite buffer, (even if atomic writes are autodetected)
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
Fallback to detecting if TRIM is enabled, if we cannot determine seek penalty.
-
- 05 May, 2019 4 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Sachin authored
If handler->inited is RND use cloned handler for long unique duplicate search.
-
- 04 May, 2019 1 commit
-
-
Sergey Vojtovich authored
Regression after reverting fair THD members constructors/destructors. vars_list can be used standalone, in such cases destructor is needed. Part of MDEV-14984 - regression in connect performance
-
- 03 May, 2019 19 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
The accessor dtuple_get_nth_v_field() was defined differently between debug and release builds in MySQL 5.7.8 in mysql/mysql-server@c47e1751b742454de553937039bbf2bcbe3c6bc7 and a debug assertion to document or enforce the questionable assumption tuple->v_fields == &tuple->fields[tuple->n_fields] was missing. This was apparently no problem until MDEV-11369 introduced instant ADD COLUMN to MariaDB Server 10.3. With that work present, in one test case, trx_undo_report_insert_virtual() could in release builds fetch the wrong value for a virtual column. We replace many of the dtuple_t accessors with const-preserving inline functions, and fix missing or misleadingly applied const qualifiers accordingly.
-
Marko Mäkelä authored
log_checkpoint(), log_make_checkpoint_at(): Remove the parameter write_always. It seems that the primary purpose of this parameter was to ensure in the function recv_reset_logs() that both checkpoint header pages will be overwritten, when the function is called from the never-enabled function recv_recovery_from_archive_start(). create_log_files(): Merge recv_reset_logs() to its only caller. Debug instrumentation: Prefer to flush the redo log, instead of triggering a redo log checkpoint. page_header_set_field(): Disable a debug assertion that will always fail due to MDEV-19344, now that we no longer initiate a redo log checkpoint before an injected crash. In recv_reset_logs() there used to be two calls to log_make_checkpoint_at(). The apparent purpose of this was to ensure that both InnoDB redo log checkpoint header pages will be initialized or overwritten. The second call was removed (without any explanation) in MySQL 5.6.3: mysql/mysql-server@4ca37968da54ddc6b3b6628f41428ddba1c79bb8 In MySQL 5.6.8 WL#6494, starting with mysql/mysql-server@00a0ba8ad92569fcf08212b3b8cf046dc8a0ce10 the function recv_reset_logs() was not only invoked during InnoDB data file initialization, but also during a regular startup when the redo log is being resized. mysql/mysql-server@45e91679832219e2593c77185342f11f85232b58 in MySQL 5.7.2 removed the UNIV_LOG_ARCHIVE code, but still did not remove the parameter write_always.
-
Eugene Kosov authored
Disable (hopefully temprorary) this check. Also add tests for some serialized functions.
-
Sergey Vojtovich authored
Originally introduced by e972125f to avoid harmless wait for LOCK_global_system_variables in a newly created thread, which creation was initiated by system variable update. At the same time it opens dangerous hole, when system variable update thread already released LOCK_global_system_variables and ack_receiver thread haven't yet completed new THD construction. In this case THD constructor goes completely unprotected. Since ack_receiver.stop() waits for the thread to go down, we have to temporarily release LOCK_global_system_variables so that it doesn't deadlock with ack_receiver.run(). Unfortunately it breaks atomicity of rpl_semi_sync_master_enabled updates and makes them not serialized. LOCK_rpl_semi_sync_master_enabled was introduced to workaround the above. TODO: move ack_receiver start/stop into repl_semisync_master enable_master/disable_master under LOCK_binlog protection? Part of MDEV-14984 - regression in connect performance
-
Sergey Vojtovich authored
Only take LOCK_plugin for plugin system variables. Reverted optimisation that was originally done for session tracker: it makes much less sense now. Specifically only if connections would want to track plugin session variables changes and these changes would actually happen frequently. If this ever becomes an issue, there're much better ways to optimise this workload. Part of MDEV-14984 - regression in connect performance
-
Sergey Vojtovich authored
Rather than parsing session_track_system_variables when thread starts, do it when first trackable event occurs. Benchmarked on a 2socket/20core/40threads Broadwell system using sysbench connect brencmark @40 threads (with select 1 disabled): 101379.77 -> 143016.68 CPS, whereas 10.2 is currently at 137766.31 CPS. Part of MDEV-14984 - regression in connect performance
-
Sergey Vojtovich authored
When enabling system variables tracker, make a copy of global_system_variables.session_track_system_variables under LOCK_global_system_variables. This protects from concurrent variable updates and potential freed memory access, as well as from variable reconstruction (which was previously protected by LOCK_plugin). We can also use this copy as a session variable pointer, so that we don't have to allocate memory and reconstruct it every time it is referenced. For this very reason we don't need buffer_length stuff anymore. As well as don't we need to take LOCK_plugin early in ::enable(). Unified ::parse_var_list() to acquire LOCK_plugin unconditionally. For no apparent reason it wasn't previously acquired for global variable update. Part of MDEV-14984 - regression in connect performance
-
Sergey Vojtovich authored
One less new/delete per connection. Removed m_mem_flag since most allocs are thread specific. The only exception are allocs performed during initialization. Removed State_tracker and Session_tracker constructors as they don't make sense anymore. No reason to access session_sysvars_tracker via get_tracker(), so access it directly instead. Part of MDEV-14984 - regression in connect performance
-
Sergey Vojtovich authored
One less new/delete per connection. Part of MDEV-14984 - regression in connect performance
-
Sergey Vojtovich authored
Saves 2 new/delete per connection. Part of MDEV-14984 - regression in connect performance
-
Sergey Vojtovich authored
tool_list is a temporary list needed only for SET SESSION session_track_system_variables, so allocate it on stack instead. Sane reinit() calls. Saves 2 new/delete per connection. Part of MDEV-14984 - regression in connect performance
-
Sergey Vojtovich authored
One less new/delete per connection. Part of MDEV-14984 - regression in connect performance
-
Sergey Vojtovich authored
- Session_sysvars_tracker::server_init_check() -> sysvartrack_validate_value() - Session_sysvars_tracker::check_var_list() -> sysvartrack_validate_value() - Session_sysvars_tracker::server_init_process() -> sysvartrack_global_update() - sysvartrack_reprint_value() -> sysvartrack_global_update() - sysvartrack_value_len() -> sysvartrack_session_value_ptr() - sysvartrack_value_construct() -> sysvartrack_session_value_ptr() - sysvartrack_update() -> Session_sysvars_tracker::update() - Session_tracker::server_boot_verify() -> session_tracker_init() - sysvar_tracker() -> /dev/null Part of MDEV-14984 - regression in connect performance
-
Sergey Vojtovich authored
- m_enabled is initialised by the base class constructor - removed unused schema_track_inited - moved Transaction_state_tracker constructor to declaration - common enable() - removed unused Session_sysvars_tracker::check_str() - classes are "private" by default - don't even try to compile for embedded Part of MDEV-14984 - regression in connect performance
-
Sergey Vojtovich authored
- return proper type - removed useless node argument - removed useless mem_flag - classes are "private" by default - simplified iterators Part of MDEV-14984 - regression in connect performance
-
Sergey Vojtovich authored
Note: preserved original behaviour, where remaining trackers are not reset on error from store(). This effectively means subsequent statements will start tracking from unclean state. Part of MDEV-14984 - regression in connect performance
-
seppo authored
Streaming replication must be allowed only in a cluster, where all nodes have Galera 4 capability
-
Varun Gupta authored
No need to set SELECT_LEX:explicit_limit when we have a limit clause that sets only the EXAMINED ROWS
-