1. Do not use NULL `info' field in processlist to select the thread of
interest. This can fail if the read of processlist ends up happening after
REAP succeeds, but before the `info' field is reset. Instead, select on the
CONNECTION_ID(), making sure we still scan the whole list to trigger the same
code as in the original test case.

2. Wait for the query to really complete before reading it in the
processlist. When REAP returns, it only means that ack has been sent to
client, the reset of query stage happens a bit later in the code.

Add missing REAP to the test.

A later test failed with strange incorrect values for COM_SELECT
in information_schema.global_status. Since global_status is updated
at the end of session activity, it seems appropriate to ensure that
all background connections have completed before accessing it.

(I checked that the original bug still triggers the test case after
the modification with REAP).

When UNIV_INTERN is missing in built-in XtraDB, this causes the
innodb_plugin to call the XtraDB version of the function instead
of its own (seen in --embedded-server test failure in Buildbot).
This in turn causes bad things to happen in case of difference
between XtranDB and innodb_plugin.

innodb_buffer_pool_pages_total depends on page size. On Power8 it is 65k
compared to 4k on Intel. As we round allocations on page size we may get
slightly more memory for buffer pool.

MDEV-6484: Assertion `tab->ref.use_count' failed on query with joins, constant table, multi-part key

- test_if_skip_sort_order()/create_ref_for_key() may change table 
  access from EQ_REF(index1) to REF(index2). 
- Doing so doesn't make much sense from optimization POV, but since 
  they are doing it, they should update tab->read_record.unlock_row
  accordingly.

revno: 4301
committer: Alexey Botchkov <holyfoot@askmonty.org>
branch nick: 10exp
timestamp: Tue 2014-07-22 15:28:15 +0500
message:
  gis-precise.test fixed to work on Power8.
------------------------------------------------------------
revno: 4295
committer: Alexey Botchkov <holyfoot@askmonty.org>
branch nick: 10exp
timestamp: Mon 2014-07-21 13:07:48 +0500
message:
  gis-precise test fixed to pass on Power8.

The data base lenth passed to invalidator fixed

* skip debian 44_scripts__mysql_config__libs.dpatch it does not apply anymore
  (and anyway it would not work for a static library)
* fix the path for install(mariadb.pc)

MDEV-5553 A view or procedure with a non existing definer can block "SHOW TABLE STATUS" with an unclear error message

Don't double-check privileges for a column in the GROUP BY that refers to
the same column in SELECT clause. Privileges were already checked for SELECT clause.

skip NULL VARCHAR key parts like it's done elsewhere

backport the new fix from 10.0

1. move cflags/libs cleanup from mysql_config.sh (runtime)
   to for_client.cmake (build time). Include/library paths are
   still calculated at runtime (they depend on the location of mysql_config)

2. Use cleaned-up cflags/libs to generate mariadb.pc

3. remove obsolete @expansions@ from mysql_config (for variables that are
   never set in cmake files)

add bsdutils dependency, because mariadb-server-5.5 deb package uses logger

apply debian's patch to workaround kfreebsd bug

and apply whatever was reasonable

typo (thanks, Brad Smith!)

stat structure (from <sys/stat.h>) is conditionally defined
to have different layout and size depending on the defined macros.
The correct macro is defined in my_config.h, which means it MUST be
included first (or, at least before <features.h> - so, practically,
before including any system headers).

            SET @@global.log_output

Deadlock chain:
rdlock(LOCK_logger) -> lock(LOCK_open)     SELECT 1
lock(LOCK_open)     -> lock(LOCK_status)   DROP TABLE t1
lock(LOCK_status)   -> lock(LOCK_g_s_v)    SHOW STATUS
lock(LOCK_g_s_)     -> wrlock(LOCK_logger) SET @@global.log_output=DEFAULT

Fixed by removing relationship between LOCK_status and
LOCK_global_system_variables during SHOW STATUS: we don't really need
LOCK_global_system_variables when accessing status vars.

            SET slow_query_log and failed connection attempt

A very subtle though valid deadlock. Deadlock chain:
wrlock(LOCK_grant)    -> lock(acl_cache->lock) GRANT/REVOKE CREATE/DROP USER
lock(LOCK_open)       -> rdlock(LOCK_grant)    SELECT * FROM I_S.COLUMNS
wrlock(LOCK_logger)   -> lock(LOCK_open)       SET @@global.slow_query_log='ON'
lock(acl_cache->lock) -> rdlock(LOCK_logger)   Failed connection

Fixed by removing relationship between acl_cache->lock and LOCK_logger
during failed connection attempt.