Use thd_get_ha_data()/thd_set_ha_data() which protect against plugin
removal until it has THD ha_data.
Do not reset THD ha_data in sphinx_close_connection(), cleaner approach
is to let ha_close_connection() do it.
Part of MDEV-19515 - Improve connect speed
Use thd_get_ha_data()/thd_set_ha_data() which protect against plugin
removal until it has THD ha_data.
Do not reset THD ha_data in mrn_close_connection(), cleaner approach
is to let ha_close_connection() do it.
Part of MDEV-19515 - Improve connect speed
Do not reset THD ha_data in spider_close_connection(), cleaner approach
is to let ha_close_connection() do it.
Part of MDEV-19515 - Improve connect speed
Use thd_get_ha_data()/thd_set_ha_data() which protect against plugin
removal until it has THD ha_data.
Do not reset THD ha_data in ha_federatedx::disconnect(), cleaner approach
is to let ha_close_connection() do it.
Part of MDEV-19515 - Improve connect speed
It was wrong anyway, as it may not get updated by the time created thread
reads it. And it was 0 for cached threads.
Part of MDEV-19515 - Improve connect speed
It may be beneficial for slow-path, where new thread is to be created.
However it is harmful for fast-path, where thread cache can fulfil
request: it caused 2 extra loads of write-contended variables.
Also shrink variables scope.
Part of MDEV-19515 - Improve connect speed
Removed FD_CLOEXEC setting: already done by mysql_socket_accept().
Moved O_NONBLOCK setting out of accepting loop.
Removed blocking acceptance attempt, which was dead code. It was supposed
to be executed before the last iteration, however it was actually executed
during the last iteration. And it is not correct to block on one socket
leaving other sockets unattended anyway.
Gives ~5% throughput improvemet in sysbench connect benchmark.
Part of MDEV-19515 - Improve connect speed
abort_loop is intended to break accepting connections loop in main thread,
however it is being used for other purposes.
cache_thread() is governed by kill_cached_threads, no need to check
abort_loop here.
Check in create_new_thread() is redundant, abort_loop already checked
by caller.
Part of MDEV-19515 - Improve connect speed
This commit adds a new feature to the server to add comments at the database
level. 1024 bytes is the maximum comment length allowed. If the comment length
exceeds this limit, a new error/warning code 4144 is thrown, based on whether
thd->is_strict_mode() is true/false. The database comment is also added to the
db.opt file, as well as to the information_schema.schemata table.
In wsrep_plugins_post_init we iterate all theads and if they are
galera appliers (wsrep_applier) we init session variables. However,
current_thd was not set and recent changes on session variables
require holding LOCK_gloal_system_variables mutex.
This is 10.4 version.
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.
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 e0c1b3f242
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
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
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.
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.
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.
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)
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
The accessor dtuple_get_nth_v_field() was defined differently between
debug and release builds in MySQL 5.7.8 in
mysql/mysql-server@c47e1751b7
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.
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@4ca37968da
In MySQL 5.6.8 WL#6494, starting with
mysql/mysql-server@00a0ba8ad9
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@45e9167983
in MySQL 5.7.2 removed the UNIV_LOG_ARCHIVE code, but still
did not remove the parameter write_always.
