don't install them at all

don't send an OK packet if the SHOW PROCESSLIST was killed

* remove bundled jemalloc, use the system one
* force jemalloc in release builds on linux

Avoided exponential recursive calls of JOIN_CACHE::join_records() in the case
of non-nested outer joins.
A different solution is required to resolve this performance problem for
nested outer joins.

fix readline/libedit detection:
* search in readline/, editline/ and edit/readline/
* fix typos CMAKE_REQUIRES_LIBRARIES -> CMAKE_REQUIRED_LIBRARIES
* use correct libedit API
* use different cmake variables for libedit and readline

MDEV-6605 Multiple Clients Inserting Causing Error: Failed to read auto-increment value from storage engine

* handler::get_auto_increment() was not expecting any errors from the storage engine.
  That was wrong, errors could happen.
* ha_partition::get_auto_increment() was doing index lookups in partition under a mutex.
  This was redundant (engine transaction isolation was covering that anyway)
  and harmful (causing deadlocks).

if it has to be a mess of ifdefs, then mess of ifdefs it is

MDEV-6595 [PATCH] HPPA: storage/xtradb/os/os0stacktrace.c:88:54: error: invalid operands to binary & (have 'void *' and 'long unsigned int')

fix precedence as in the patch from Brian Evans

  if it's run on a real disk
  
  Made test smaller.

only look at lex->option_type if it's a SHOW command, not a SELECT

MDEV-6483 - Deadlock around rw_lock_debug_mutex on PPC64

This problem affects only debug builds on PPC64.

There are at least two race conditions around
rw_lock_debug_mutex_enter and rw_lock_debug_mutex_exit:

- rw_lock_debug_waiters was loaded/stored without setting
  appropriate locks/memory barriers.
- there is a gap between calls to os_event_reset() and
  os_event_wait() and in such case we're supposed to pass
  return value of the former to the latter.

Fixed by replacing self-cooked spinlocks with system mutexes.
These days system mutexes offer much better performance. OTOH
performance is not that critical for debug builds.

MDEV-6450 - MariaDB crash on Power8 when built with advance tool
            chain

InnoDB mutex_exit() function calls __sync_test_and_set() to release
the lock. According to manual this function is supposed to create
"acquire" memory barrier whereas in fact we need "release" memory
barrier at mutex_exit().

The problem isn't repeatable with gcc because it creates
"acquire-release" memory barrier for __sync_test_and_set().
ATC creates just "acquire" barrier.

Fixed by creating proper barrier at mutex_exit() by using
__sync_lock_release() instead of __sync_test_and_set().

MDEV-6601 Assertion `!thd->in_active_multi_stmt_transa ction() || thd->in_multi_stmt_transaction_mode()' failed on executing a stored procedure with commit

Don't restore the whole of thd->server_status after a routine invocation,
only restore SERVER_STATUS_CURSOR_EXISTS and SERVER_STATUS_LAST_ROW_SENT,
as --ps --embedded needs.
In particular, don't restore SERVER_STATUS_IN_TRANS.

Part of this work is based on Stewart Smitch's memory barrier and lower priori
patches for power8.

- Added memory syncronization for innodb & xtradb for power8.
- Added HAVE_WINDOWS_MM_FENCE to CMakeList.txt
- Added os_isync to fix a syncronization problem on power
- Added log_get_lsn_nowait which is now used srv_error_monitor_thread to ensur
  if log mutex is locked.

All changes done both for InnoDB and Xtradb

Change a couple of permissions that cause lintian warnings in .deb packaging and don't really hurt to fix.

sporadically

Fix: Modify test to be smaller so that testcase timeout does not
trigger. We already have a test for --big-test setup
(innodb.innodb_simulate_comp_failures).

Followup. Don't compile threadpool_unix.cc when thread pool is disabled

disable tokudb paranoid asserts

Fix the bug properly (plugin cannot be unloaded as long as it's locked).
Enable and fix the test case.
Significantly reduce number of LOCK_plugin locks for semisync
(practically all locks were removed)

~40% bugfixed(*) applied
~40$ bugfixed reverted (incorrect or we're not buggy)
~20% bugfixed applied, despite us being not buggy
(*) only changes in the server code, e.g. not cmakefiles

Do not define a look-up key for a temporary table if its length
exceeds the maximum length of such keys. 

mysql_derived_prepare() was executed on the statement memory.
Now it is executed on the runtime memory.
All bugs induced by this were fixed.

Fix for MDEV-6493: Assertion `table->file->stats.records > 0 || error' failure, or 'Invalid write' valgrind warnings, or crash on scenario with Aria table, view, LOCK TABLES

This bug only happens in case of paritioned tables used in LOCK TABLES and implicit_commit() was called
(as part of trying to execute a CREATE TABLE withing lock tables)

The problem was that Aria could not move the tables from one transaction to the new one, as thd->open_tables contained
a partitioned tables and not an Aria table.

Fix:
- Store a list of all open tables that are part of a share in share->open_tables
- In maria::implict_commit() use transaction->used_tables & share->open_tables to find out which tables
  was part of the current transaction instead of using thd->open_tables, which may contain partitioned tables.


mysql-test/suite/maria/maria_partition.result:
  Added test case
mysql-test/suite/maria/maria_partition.test:
  Added test case
storage/maria/ha_maria.cc:
  Use trn->used tables and share->open_tables to find out which tables was part of the current transaction instead of using thd->open_tables.
storage/maria/ma_close.c:
  Remove closed table from share->open_list
storage/maria/ma_open.c:
  Add table to share->open_list
storage/maria/ma_state.c:
  Added comment
storage/maria/maria_def.h:
  Added share->open_list, a list of all tables that is using this share.

* remove incorrect assertion (it didn't take into account concurrent clients)
* fix the comment