The loop in the binary search in remove_status_vars() was
incorrectly implemented and could continue infinitely in some cases.
Rewrote the binary search code.
An addition to fix for MDEV-5205, fixes server crash on shutdown.
Thread groups are destroyed asynchronously, that is kill server
thread sends shutdown request to all thread groups without waiting
for compeltion.
It means all_groups array must not be freed until all thread groups
are down. This patch suggests that all_groups is freed when last
thread group is destroyed.
Note 1: threadpool code doesn't surround atomic ops with atomic locks,
thus no locks for shutdown_group_count.
Note 2: this patch preserves old behaviour, but we may need to wait
until all thread groups are down before returning from tp_end().
include/CMakeLists.txt:
Added handler_ername.h
include/handler_ername.h:
Names of handler error messages
mysql-test/extra/binlog_tests/binlog.test:
Test using handler error names
mysql-test/r/mysqltest.result:
Update for new error message
mysql-test/t/auto_increment.test:
Test using handler error names
mysql-test/t/auto_increment_ranges.inc:
Test using handler error names
mysql-test/t/replace.test:
Test using handler error names
- thread_pool_size command line option upper limit increased to 100 000
(same as for max_connections)
- thread_pool_size system variable upper limit is maximum of 128 or
the value given at command line
- thread groups are now allocated dynamically
Different limit for command line option and system variable was done to
avoid additional mutex for all_groups and threadpool_max_size.
There was 2 problems:
1) coping/moving of the same type (usually casting) as sizeof() (solved in different ways depends on the cause);
2) using 'const' in SSL_CTX::getVerifyCallback() which return object (not reference) and so copy of the object will be created and 'const' has no sens.
Analysis:
st_select_lex_unit::prepare() computes can_skip_order_by as TRUE.
As a result join->prepare() gets called with order == NULL, and
doesn't do name resolution for the inner ORDER clause. Due to this
the prepare phase doesn't detect that the query references non-exiting
function and field.
Later join->optimize() calls update_used_tables() for a non-resolved
Item_field, which understandably has no Field object. This call results
in a crash.
Solution:
Resolve unnecessary ORDER BY clauses to detect if they reference non-exising
objects. Then remove such clauses from the JOIN object.
- Backport MySQL's fix: do set ha_partition::m_pkey_is_clustered for ha_partition
objects created with handler->clone() call.
- Also, include a testcase.
Slackware install docs to different folder, which wasn't handled
by file_contents test properly. E.g. on Redhat/Debian docs are
expected to be in /usr/share/doc/mariadb-server-(version), but
on Slackware they are in /usr/doc/mariadb-(version).
For details see Slackware mariadb build script:
http://slackbuilds.org/slackbuilds/14.0/system/mariadb/mariadb.SlackBuild
MDEV-5034:Wrong result on LEFT JOIN with a SELECT SQ or a merge view, UNION in IN subquery
Make reset null_row same as it was set in evaluate_null_complemented_join_record().
The problem was that view firlds detect null_row by not-yet-reset table.
Objects of the classes Item_func_isnull and Item_func_isnotnull
must have the flag sargable set to TRUE.
Set the value of the flag sargable only in constructors of the
classes inherited from Item_int_func.
The bug caused a memory overwrite in the function update_ref_and_keys()
It happened due to a wrong value of SELECT_LEX::cond_count. This value
historically was calculated by the fix_fields method. Now the logic of
calling this method became too complicated and, as a result, this value
is calculated not always correctly.
The patch changes the way how and when the values of SELECT_LEX::cond_count
and of SELECT_LEX::between_count are calculated. The new code does it just at
the beginning of update_ref_and_keys().
change minicron to count the period from the beginning of
the callback's execution and not the end. For checkpoints, this makes them
reliably start every 60 seconds.
