it used current_thd->alloc() and allocated on the thd's execution arena,
not on table->expr_arena.

Remove THD::arena_for_cached_items that is temporarily set in
update_virtual_fields(), and replaces THD arena in get_datetime_value().
Instead set THD arena to table->expr_arena for the whole  duration
of update_virtual_fields()

Item_func_le included Arg_comparator. Arg_comparator remembered
the current_thd during fix_fields and used that value during
execution to allocate Item_cache in get_datetime_value().
But for vcols fix_fields and val_int can happen in different threads.

Same bug for Item_func_in using in_datetime or cmp_item_datetime,
both also remembered current_thd at fix_fields() to use it later
for get_datetime_value().

As a fix, these objects no longer remember the current_thd,
and get_datetime_value() uses current_thd at run time. This
should not increase the number of current_thd calls much, as
Item_cache is created only once anyway.

don't check defaults for vcols

MDEV-11706 Assertion `is_stat_field || !table || (!table->write_set || bitmap_is_set(table->write_set, field_index) || (table->vcol_set && bitmap_is_set(table->vcol_set, field_index)))' failed in Field_time::store_TIME_with_warning

vcols and triggers. Revert 094f4cf7,
backport the correct fix (Table_triggers_list::mark_fields_used() not
marking vcols) from 10.2.

The supplied sql_mode(s) should be converted to ASCII first,
before comparing it with the sql_mode set.

compile, and install selinux policy for mysqld_safe_helper on centos6.
the policy was created as described in https://mariadb.com/kb/en/mariadb/what-to-do-if-mariadb-doesnt-start/#other-selinux-changes

c3cf7f47 reverted the patch
for BUG#24487120. After merging the reverting patch from MySQL
to MariaDB the problems described in MDEV-11079 and MDEV-11631 disappeared.
Adding test cases only.

The fix for bug mdev-5104 did not take into account that
for any call of setup_order the size of ref_array must
be big enough. This patch fixes this problem.

The warning is "blocks are still reachable in loss record",
happens in malloc / _dl_close_worker. Suppression added

When the test is run as a part of the suite with valgrind,
only allow it to be executed if --big-test is set.
If the test is run by specifying its name explicitly, it
will still be executed, even with valgrind without big-test,
MTR has special logic for that

The guilty part of the test checks for performance degradation on
a query with numerous joins on an empty table. The test expects
the query to take less than 1 second, and fails if it is not so
(which can happen on very slow builders).

The solution is to add more JOINs to the query. On a fixed server,
it should not have any noticeable impact on the query execution,
while on the unfixed version the query would take several times
longer (e.g. 6.5 sec vs 1.5 sec). Thus, we can increase the margin
for the error, and make the test fail when the query takes longer
than 5 seconds.

correct the error message in case of setuid/setgid failures

Backport the fix to 5.5, because it fails there too

The patch fixes two test failures:
- on slow builders, sometimes a connection attempt which should
  fail due to the exceeded number of thread_pool_max_threads
  actually succeeds;
- on even slow builders, MTR sometimes cannot establish the
  initial connection, and check-testcase fails prior to the
  test start

The problem with check-testcase was caused by connect-timeout=2
which was set for all clients in the test config file. On slow
builders it might be not enough.
There is no way to override it for the pre-test check, so it needed
to be substantially increased or removed.

The other problem was caused by a race condition between sleeps
that the test performs in existing connections and the connect
timeout for the connection attempt which was expected to fail.
If sleeps finished before the connect-timeout was exceeded, it
would allow the connection to succeed.

To solve each problem without making the other one worse,
connect-timeout should be configured dynamically during the test.
Due to the nature of the test (all connections must be busy
at the moment when we need to change the timeout, and cannot execute
SET GLOBAL ...), it needs to be done independently from the server.

The solution:
- recognize 'connect_timeout' as a connection option in mysqltest's
  "connect" command;
- remove connect-timeout from the test configuration file;
- use the new connect_timeout option for those connections which
  are expected to fail;
- re-arrange the test flow to allow running a huge SLEEP
  without affecting the test execution time (because it would be
  interrupted after the main test flow is finished).

The test is still subject to false negatives, e.g. if the connection
fails due to timeout rather than due to the exceeded number of
allowed threads, or if the connection on extra port succeeds due
to a race condition and not because the special logic for the extra
port. But those false negatives have always been possible there
on slow builders, they should not be critical because faster builders
should catch such failures if they appear.

Conflicts:
	client/mysqltest.cc
	mysql-test/r/pool_of_threads.result
	mysql-test/t/pool_of_threads.test

main.log_slow might leave mysql.slow_log table non-empty,
and tests which later use it might fail. Make sure that the table
is properly truncated

and use is_supported_parser_charset() instead of direct check

In file sql/filesort.cc,when merge_buffers() is called then
- queue_remove(&queue,0) is called
- For the function queue_remove there is assertion states that the element to be removed should have index >=1
- this is causing the assertion to fail.

Fixed by removing the top element.

MDEV-10386 Assertion `fixed == 1' failed in virtual String* Item_func_conv_charset::val_str(String*)

The patch b96c196f added a new call for
safe_charset_converter() without a corresponding fix_fields().
In case of a sub-query the created Item remained in non-fixed state.
The problem did not show up with literal derived expressions, only
subselects were affected. This patch adds a corresponding fix_fields()
to the previously added safe_charset_converter().

Added test case.

Do not use 0x%p to output thd address, use %p

count duplicate of UNION SELECT separately to awoid influence on lokal LIMIT clause.

Fix st_select_lex::is_merged_child_of to work across merged views or
derived tables.

The bug occurred when a subquery
- has a reference to outside, to grand-parent query or further up
- is converted to a semi-join (i.e. merged into its parent).

Then the reference to outside had form Item_ref(Item_field(...)).
- Conversion to semi-join would call item->fix_after_pullout() for the
  outside reference.
- Item_ref::fix_after_pullout would call Item_field->fix_after_pullout
- The Item_field would construct a new Name_resolution_context object
  This process ignored the fact that the Item_field does not belong to
  any of the subselects being flattened.
The result was crash in the next call to Item_field::fix_fields(), where
we would try to use an invalid Name_resolution_context object.

Fixed by not creating Name_resolution_context object if the Item_field's
context does not belong to the subselect(s) that were flattened.

MDEV-10274 Bundling insert with create statement for table with unsigned Decimal primary key issues warning 1194.

        Flags are important for key_length calculations, so them should
        be set before it, not after.

This change is a backport from 10.0 to 5.5 for:
1. The full patch for:
     MDEV-4841 Wrong character set of ADDTIME() and DATE_ADD()
     9adb6e99

2. A small fragment of:
     MDEV-5298 Illegal mix of collations on timestamp
     03f6778d
   which overrides Item_temporal_hybrid_func::cmp_type(),
   and adds a new line into cache_temporal_4265.result.

double the timeout for threads to die on shutdown

some trivial simplifications. drinking the ocean,
one drop at a time

MDEV-11552 Queries executed by event scheduler are written to slow log incorrectly or not written at all

because thd->update_server_status() is used to measure the query time
for the slow log (not only to set protocol level flags),
it needs to be called also when the server isn't going to send
anything to the client.

        MySQL has a bug failing to handle
           MYSQL_THDVAR_STR(...  PLUGIN_VAR_NOSYSVAR |
                                 PLUGIN_VAR_NOCMDOPT | PLUGIN_VAR_MEMALLOC)
        so fall back to just PLUGIN_VAR_READONLY | PLUGIN_VAR_MEMALLOC
        whem MySQL started.

MDEV-10713: signal 11 error on multi-table update - crash in handler::increment_statistics or in make_select or assertion failure pfs_thread == ((PFS_thread*) pthread_getspecific((THR_PFS)))

Different fix. Don't allow Item_func_sp to be evaluated unless
all tables are prelocked.

Extend the test case to make sure Item_func_sp::val_str is called
(the table must have at least one row for that).

Revert "MDEV-10713: signal 11 error on multi-table update - crash in handler::increment_statistics or in make_select or assertion failure pfs_thread == ((PFS_thread*) pthread_getspecific((THR_PFS)))"

This reverts commit 035a5ac6.

Two minor problems and one regression:
1. caching the value in str_result. Other Item methods may use it,
   destroying the cache. See, for example, Item::save_in_field, where
   str_result is moved to use a local buffer (this failed main.grant)
2. Item_func_conv_charset::safe is now set too late, it's initialized
   only in val_str() but checked before that, this failed many tests
   in optimized builds.

to fix 1 - use tmp_result instead of str_result, to fix 2, use
the else branch in the Item_func_conv_charset constructor to set
safe purely from charset properties.

But this introduces a regression, constant strings can no longer be
converted, say, from utf8 to latin1 (because 'safe' will be false).
This fails few tests too. There is no way to fix it without reverting
the commit and converting constants, as before, in the constructor.