Tests were failing because in TIME_from_longlong_datetime_packed() GCC8
at -O2 assumed that tmp is always positive and used mul and shr while it
used imul and sar at -O1 (where tests passed). GCC8 used multiplication
(by 0x4ec4ec4ec4ec4ec5) and shift to implement division by 13. It could
assume that tmp is always positive, because the function starts with
`if (tmp < 0) tmp= -tmp;`

But this assumption breaks if tmp=0x8000000000000000;
This is invalid value and TIME_from_longlong_datetime_packed() should
never see it, garbage in - garbage out.

It was getting this invalid value because mroonga tried to convert a
NULL key part to MYSQL_TIME. If the key part value is NULL, datetime2
value of it happens to be bzero-ed, which is invalid binary datetime2
value.

The correct behavior is not to try to interpret the key part value, if
it is marked as NULL. But this minimal fix only covers the datetime2 type.

According to logs analysis the Dump thread attempted to read again data which
was already sent. The reason of regressed read turns out in an _my_b_cache_read()
early exit branch which missed to distinguish between total zero size read (e.g
ineffective read when Count argument is zero) from a case when the
requested amount of data is fully read out by sole accessing the cache's
file. In the latter case such then *effective* reading was not
reflected in the cache's state to screw the cache's state.

Fixed with a check introduced of whether the file reading was effective prior to
early exit. When this is the case conduct standard cache state change to
account the actual read size.

Notice the bug can show up also as an error to read binlog event e.g
through BINLOG_GTID_POS() (of MDEV-16886).

On some archs uclibc does not provide the ucontext structure despite
providing ucontext.h, for details see
https://git.buildroot.net/buildroot/commit/?id=f1cbfeea95e6287c7a666aafc182ffa318eff262

This patch improves the detection of ucontext by making sure that
HAVE_UCONTEXT_H is only set when makecontext() was found.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>

The test and also rpl_gtid_delete_domain failed on PPC64 platform
due to an incorrectly specified actual key for searching
in a gtid domain system hash. While the correct size is 32 bits
the supplied value was 8 bytes of long int size on the platform.
The problem became evident thanks to the big endiness which
cut off the *least* significant part of the value field.

Fixed with correcting a dynamic array initialization to hold
now uint32 values as well as the values extraction for
searching in the gtid domain system hash.
A new added test ensures no overflowed values are accepted
for deletion which prevents inadvertent action. Notice though

MariaDB [test]> set @@session.gtid_domain_id=(1 << 32) + 1;
MariaDB [test]> show warnings;
+---------+------+--------------------------------------------------------+
| Level   | Code | Message                                                |
+---------+------+--------------------------------------------------------+
| Warning | 1292 | Truncated incorrect gtid_domain_id value: '4294967297' |
+---------+------+--------------------------------------------------------+
MariaDB [test]> select @@session.gtid_domain_id;
+--------------------------+
| @@session.gtid_domain_id |
+--------------------------+
|               4294967295 |
+--------------------------+

use FreeContextAttributes() on individual members of
SecPkgContext_NativeNames, not on the struct itself.

Add wait on second node.

if thread specific memory is requested and current_thd is NULL.

Leave DBUG_ASSERT() in place, to check in DBUG version.

The bug appears as a slave SQL thread hanging in
rpl_parallel_thread_pool::get_thread() while there are no slave worker
threads to awake it.

The reason of the hang is that at the parallel slave worker pool
activation the being stared SQL thread could read the worker pool size
concurrently with pool deactivation. At reading the SQL thread did not
employ necessary protection from a race.

Fixed with making the SQL thread at the pool activation first
to grab the same lock as potential deactivator also does prior
to access the pool size.

           derived table / view by equality

Now rows of a materialized derived table are always put into a
temporary table before join operation. If BNLH is used to join this
table with the result of a partial join then both operands of the
join are actually put into main memory. In most cases this is not
efficient.
We could avoid this by sending the rows of the derived table directly
to the join operation. However this kind of data flow is not supported
yet.
Fixed by not allowing usage of hash join algorithm to join a materialized
derived table if it's joined by an equality predicate of the form
f=e where f is a field of the derived table.

This would happen especially in optimistic parallel replication, where there
is a good chance that a transaction will be rolled back (due to conflicts)
after it has executed record_gtid(). If the transaction did any deletions of
old rows as part of record_gtid(), those deletions will be undone as well.
And the code did not properly ensure that the deletions would be re-tried.

This patch makes record_gtid() remember the list of deletions done as part
of a transaction. Then in rpl_slave_state::update() when the changes have
been committed, we discard the list. However, in case of error and rollback,
in cleanup_context() we will instead put the list back into
rpl_global_gtid_slave_state so that the deletions will be re-tried later.

Probably fixes part of the cause of MDEV-12147 as well.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>

MDEV-17313 Data race in ib_counter_t

pthread_detach_this_thread() was intended to be defined to something
meaningful only on some ancient unixes, which don't have
pthread_attr_setdetachstate() defined. Otherwise, on normal unixes,
threads are created detached in the first place.

This was broken in 0f01bf26 so that
we started calling pthread_detach() for already detached threads.
Intention was to detach aria checkpoint thread.

However in 87007dc2 aria service threads
were made joinable with appropriate handling, which makes breaking
revision unneccessary.

Revert remnants of 0f01bf26, so that
pthread_detach_this_thread() is meaningful only on some ancient unixes
again.

SLES11 can't build currently latest Galera library version.

Add wait until cluster has correct number of nodes.

ib_counter_t: make all reads/writes to m_counter relaxed atomical

MDEV-16656: DROP DATABASE crashes the Galera Cluster

When converting table identifiers to a new format,
some tables can be renamed twice, which subsequently
leads to the appearance of "false" auxiliary tables
belonging to another main (parent) table (which does
not actually have auxiliary tables).

This is because the table number is repeatedly added
to the aux_tables_to_rename vector inside the function
fts_check_and_drop_orphaned_tables.

To correct this error, we must add a check for the
occurrence of the table number in the aux_tables_to_rename
vector before adding a new element.

https://jira.mariadb.org/browse/MDEV-16656

Reset query cache after every test case and add wait after
load infile.

to guarantee that it's destroyed when plugin deinit is called, not after

Unary minus operation for the smallest possible signed long long value
(LONLONG_MIN) is undefined in C++. Because of this, func_time.test
failed on ppc64 buildbot machines.

Fixing the code to avod using undefined operations.

This is fix is similar to "MDEV-7973 bigint fail with gcc 5.0"

alloc_root(): unpoison only requested amount of bytes instead of a
possible bigger aligned-sized buffer.