innodb_buffer_pool_populate has not had an effect since 10.0.23
in commit 1e270d50 when its
functionality was removed.

As we've only just enabled LIBNUMA in MDEV-10829 it isn't logical
to have innodb_buffer_pool_populate aliasing for innodb_numa_interleave
this late in the game.

So the simpliest way is just to remove innodb_buffer_pool_populate.
Signed-off-by: Daniel Black <daniel.black@au.ibm.com>

The bug was fixed by the patch for mdev-10882.

The implementation of the virtual method build_clone for
the class Item_cache was missing.

        Some fixes made in innodb and item_create.cc.
        Adapted Innodb-GIS tests moved to MariaDB.

For backwards compatibility reasons.

E.g. innotop builds against libmysqlclient.so and expects to find
a libmysqlclient.so.18 library and does not use libmariadb.so.3 even
when built from our own sources.

This commit mimics to dcfe6cb8

This change was accidentally omitted from commit 2bcc16c1

As libmariadb.so.3 does not reside in a multi-arch directory (yet),
use the plain path.

This patch adds DEFAULT as a possible dynamic SQL parameter, e.g.:
  EXECUTE IMMEDIATE 'INSERT INTO t1 (column) VALUES(?)' USING DEFAULT;
  EXECUTE IMMEDIATE 'UPDATE t1 SET column=?' USING DEFAULT;
and for similar PREPARE..EXECUTE queries.

This is done for symmetry with the STMT_INDICATOR_DEFAULT indicator in
the client-server PS protocol.

The changes include:
- Allowing DEFAULT as a possible option in execute USING clause (sql_yacc.yy)
- Adding "virtual bool Item::save_in_param(THD *thd, Item_param *param)",
  because "normal" items (that have real values) and Item_default_value
  have now different actions when assigning itself as an Item_param value.
- Fixing switch() statements in a few Item_param methods not to have "default",
  because it was easy to forget to add a new "case" when adding a new XXX_VALUE
  value into the enum Item_param::enum_item_param_state.
  This is important, as we'll be adding new values soon, e.g. for MDEV-11359.
  Removing "default" helped to find and report bugs MDEV-11361 and MDEV-11362,
  because DECIMAL_VALUE is obviously not properly handled in some cases.

The fix for bug 11072 was not complete though it also fixed
the bug mdev-10800.
This patch resolves the problems of all three bugs.

Fall back to old iproute on Debian Wheezy and Ubuntu Precise that
don't have iproute2 available.

Revert the XtraDB changes, because 10.2 does not currently build with XtraDB.

Also omit some changes that need further investigation.

Ensure that all callers of partition_info::get_clone() are passing this!=NULL.

buf_block_init(): Initialize buf_page_t::flush_type.
For some reason, Valgrind 3.12.0 would seem to flag some
bits in adjacent bitfields as uninitialized, even though only
the two bits of flush_type were left uninitialized. Initialize
the field to get rid of many warnings.

buf_page_init_low(): Initialize buf_page_t::old.
For some reason, Valgrind 3.12.0 would seem to flag all 32
bits uninitialized when buf_page_init_for_read() invokes
buf_LRU_add_block(bpage, TRUE). This would trigger bogus warnings
for buf_page_t::freed_page_clock being uninitialized.
(The V-bits would later claim that only "old" is initialized
in the 32-bit word.) Perhaps recent compilers
(GCC 6.2.1 and clang 4.0.0) generate more optimized x86_64 code
for bitfield operations, confusing Valgrind?

mach_write_to_1(), mach_write_to_2(), mach_write_to_3():
Rewrite the assertions that ensure that the most significant
bits are zero. Apparently, clang 4.0.0 would optimize expressions
of the form ((n | 0xFF) <= 0x100) to (n <= 0x100). The redundant
0xFF was added in the first place in order to suppress a
Valgrind warning. (Valgrind would warn about comparing uninitialized
values even in the case when the uninitialized bits do not affect
the result of the comparison.)

In functions that declare pointer parameters as nonnull,
remove nullness checks, because GCC would optimize them away anyway.

Use #ifdef instead of #if when checking for a configuration flag.

Clang says that left shifts of negative values are undefined.
So, use ~0U instead of ~0 in a number of macros.

Some functions that were defined as UNIV_INLINE were declared as
UNIV_INTERN. Consistently use the same type of linkage.

ibuf_merge_or_delete_for_page() could pass bitmap_page=NULL to
buf_page_print(), conflicting with the __attribute__((nonnull)).

Threads may fall asleep forever while acquiring InnoDB rw-lock on Power8. This
regression was introduced along with InnoDB atomic operations fixes.

The problem was that proper memory order wasn't enforced between "writers"
store and "lock_word" load:

  my_atomic_store32((int32*) &lock->waiters, 1);
  ...
  local_lock_word = lock->lock_word;

Locking protocol is such that store to "writers" must be completed before load
of "lock_word". my_atomic_store32() was expected to enforce memory order because
it issues strongest MY_MEMORY_ORDER_SEQ_CST memory barrier.

According to C11:
- any operation with this memory order is both an acquire operation and a
  release operation
- for atomic store order must be one of memory_order_relaxed
  memory_order_release or memory_order_seq_cst. Otherwise the behavior is
  undefined.

That is it doesn't say explicitly that this expectation is wrong, but there are
indications that acquire (which is actually supposed to guarantee memory order
in this case) may not be issued along with MY_MEMORY_ORDER_SEQ_CST.

A good fix for this is to encode waiters into lock_word, but it is a bit too
intrusive. Instead we change atomic store to atomic fetch-and-store, which
does memory load and is guaranteed to issue acquire.

Simplify away recursive flag: it is not necessary for rw-locks to operate
properly. Now writer_thread != 0 means recursive.

As we only need correct value of writer_thread only in writer_thread itself
it is rather safe to load and update it non-atomically.

This patch also fixes potential reorder of "writer_thread" and "recursive"
loads (aka MDEV-7148), which was reopened along with InnoDB thread fences
simplification. Previous versions are unaffected, because they have os_rmb
in rw_lock_lock_word_decr(). It wasn't observed at the moment of writing
though.

Clean-up INNODB_RW_LOCKS_USE_ATOMICS: it is always set.

Simplified away rw_lock_get_waiters(), rw_lock_set_waiter_flag(),
rw_lock_reset_waiter_flag(). Let waiters have predictable data type.

Simplified away rw_lock_lock_word_incr().

This is required, as the innochecksum binary has moved package.
Without this change the following error would be emitted:

  Unpacking mariadb-server-core-10.2 (10.2.3+maria~jessie) over (10.2.2+maria-1~jessie) ...
  dpkg: error processing archive /var/cache/apt/archives/mariadb-server-core-10.2_10.2.3+maria~jessie_amd64.deb (--unpack):
    trying to overwrite '/usr/bin/innochecksum', which is also in package mariadb-client-10.2 10.2.2+maria-1~jessie

Quite often in upgrades on systemd systems dpkg emitted an error like:

  Failed to stop mysql.service: Unit mysql.service not loaded.
  invoke-rc.d: initscript mysql, action "stop" failed.
  invoke-rc.d returned 5
  There is a MySQL server running, but we failed in our attempts to stop it.
  Stop it yourself and try again!
  dpkg: error processing archive /var/cache/apt/archives/mariadb-server-10.2

This is because the mariadb/mysql.service file is not loaded during
the upgrade/unpack stage of dpkg in certain situations. With this simple
check we can easily skip the shutdown step when it is really not needed,
which is for sure the case if no mysqld process at all is running on the
entire system.

capabilities(in upper 32bits) were sent as 0 on 32bit Windows. They were
reset because CLIENT_SSL, CLIENT_COMPRESS and CLIENT_SSL_VERIFY_SERVER_CERT were defined as UL
Plus MARIADB_CLIENT_STMT_BULK_OPERATIONS was defined as 1UL << 34, and that is undefined operation.

There were no implementations for the virtual functions
exclusive_dependence_on_table_processor and
exclusive_dependence_on_table_processor. As a result
the procedure pushdown_cond_for_derived erroneously
detected some conditions with outer references as pushable
into materialized view / derived table.

MDEV-10724 Assertion `vcol_table == 0 || vcol_table == table' failed in fill_record(THD*, TABLE*, List<Item>&, List<Item>&, bool, bool)

Attempt to insert in several tables now checked just by table map.

.. (MDL_key::TABLE, table->db, table->table_name, MDL_SHARED)'
failed in mysql_rm_table_no_locks

Reset error flag after temporary table has been
successfully dropped.

SST processes should inherit mysqld's process group.

  - Make rsync process checks OS-dependent
  - Use (BSD) netstat on FreeBSD (not lsof)

  - Replace #!/bin/bash with #!/bin/sh
  - Split username:password using POSIX compat %% and ##
  - Don't use array for FILTERS
  - Replace == tests with POSIX-compat =

The idea of this fix was taken from the patch by Roy Lyseng
for mysql-5.6 bug iBug#14740889: "Wrong result for aggregate
functions when executing query through cursor".

Here's Roy's comment for his patch:
"
The problem was that a grouped query did not behave properly when
executed using a cursor. On further inspection, the query used one
intermediate temporary table for the grouping.
Then, Select_materialize::send_result_set_metadata created a temporary
table for storing the query result. Notice that get_unit_column_types()
is used to retrieve column meta-data for the query. The items contained
in this list are later modified so that their result_field points to
the row buffer of the materialized temporary table for the cursor.
But prior to this, these result_field objects have been prepared for
use in the grouping operation, by JOIN::make_tmp_tables_info(), hence
the grouping operation operates on wrong column buffers.

The problem is solved by using the list JOIN::fields when copying data
to the materialized table. This list is set by JOIN::make_tmp_tables_info()
and points to the columns of the last intermediate temporary table of
the executed query. For a UNION, it points to the temporary table
that is the result of the UNION query.

Notice that we have to assign a value to ::fields early in JOIN::optimize()
in case the optimization shortcuts due to a const plan detection.

A more optimal solution might be to avoid creating the final temporary
table when the query result is already stored in a temporary table.
"
The patch does not contain a test case, but the description of the
problem corresponds exactly what could be observed in the test
case for mdev-11081.

Instead of restart_mysqld.inc, truncate the P_S tables that are used
by the test. We don't want to query some irrelevant data.

The motivation for this is that Perl is moving towards not having
current directory ./ in @INC by default. This is causing
mysql-test-run.pl to fail in latest Debian Unstable:

  https://lists.debian.org/debian-devel-announce/2016/08/msg00013.html

However, we have `use "lib"`, there is no need for current directory
in @INC, except for a gross hack. In mtr_cases.pm, there is a
`require "mtr_misc.pl"`, which hides mtr_misc.pl away in mtr_cases
namespace. And things only work because mysql-test-run.pl loads it
with a different name, `require "lib/mtr_misc.pl"`! (Perl will
`require` only once for each unique filename).

Fix this by only using `require` in main program, and referencing
functions with :: scope from other namespaces. For multi-use in
different namespaces, proper `use` modules should be used.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>

This way all 3rd party apps configured to build against any MySQL or
MariaDB version will pick up the libmariadb3-dev package instead.