Post-fix:
Reverting the patch for MDEV-6069 brought some ALTERs with
ENGINE=MYISAM back into the mysql_system_tables_fix.sql
script. As a result, running mysql_upgrade with global
enforce_storage_engine=INNODB (or any other non-MyISAM
engine, for that matter) would fail.

Fixed by locally unsetting enforce_storage_engine in the
upgrade script.

The verifier exception is caused by using thread local storage key
after key was deleted.

my_free() used current_thd within malloc size callback, which does
pthread_get_specific(THR_THD), but THR_THD is already deleted at this
point.

The fix moves pthread_key_delete() to a later point in shutdown.

This reverts commit 5e6f1236.

This reverts commit f8381d93.

Test used aes_ctr that is not available everywhere when aes_cbc is fine also
for this test.

Some modifications in galera_new_cluster :

* Do not use absolute path for systemctl
* Fix parameter substitution syntax

Now this error out and refers to galera_new_cluster.

Use galera_new_cluster instead. systemctl start mariadb@bootstrap
will generate error message, use_galera_new_cluster.conf is the name
of the file that will generate this error.

Output:

Job for mariadb@bootstrap.service failed. See "systemctl status
mariadb@bootstrap.service" and "journalctl -xe" for details.

● mariadb@bootstrap.service - MariaDB database server
   Loaded: loaded (/usr/lib/systemd/system/mariadb@.service; disabled;
vendor preset: disabled)
  Drop-In: /usr/lib/systemd/system/mariadb@bootstrap.service.d
           └─use_galera_new_cluster.conf
   Active: failed (Result: exit-code) since Thu 2015-10-15 19:27:52
CEST; 5s ago
  Process: 24334 ExecStart=/usr/bin/false (code=exited,
status=1/FAILURE)
  Process: 24330 ExecStart=/usr/bin/echo Please use galera_new_cluster
to start the mariadb service with --wsrep-new-cluster (code=exited,
status=0/SUCCESS)
 Main PID: 24334 (code=exited, status=1/FAILURE)

Oct 15 19:27:52 spaceman systemd[1]: Starting MariaDB database server...
Oct 15 19:27:52 spaceman systemd[1]: mariadb@bootstrap.service: main
process exited, code=exited, status=1/FAILURE
Oct 15 19:27:52 spaceman systemd[1]: Failed to start MariaDB database
server.
Oct 15 19:27:52 spaceman systemd[1]: Unit mariadb@bootstrap.service
entered failed state.
Oct 15 19:27:52 spaceman systemd[1]: mariadb@bootstrap.service failed.

        we don't test for not-existing gis extra in FRM.

Add comment about bind-address mentioned under galera section.

Redo log encryption used too short buffer when getting
encryption keys.

Part 2: removed hack workaround for bug we do not have.

small sixes of used_tables() usage

* clarify the comment in the preset file
* make boolean --aria-encrypt-tables option to work without an argument

Restore changes that were lost in a merge. Originally from

commit 66fd45af
Author: Sergei Golubchik <serg@mariadb.org>
Date:   Mon Jun 8 21:06:56 2015 +0200

    MDEV-7398 mysqld segfaults on FreeBSD 10.1 i386 when built with clang 3.4

Problem is that we expect key_version to be increasing so
before we reset debug_key_management plugin key_version
disable encryption.

Add diagnostics when externally stored field is freed but
rollback ctx is not what we expect.

At least some of the failures where due to fact that TMPDIR contained
old file.

Incorrect parameter type was used. Fixed by casting data types to correct
ones.

THD is already available in Protocol

and ErrConvString::ErrConvString(String *).

The fix for MDEV-8918 previously fixed the problem reported in MDEV-7195.
Adding a test case from MDEV-7195 only.

create_embedded_thd() must reset current_thd before returning,
otherwise client [de-]allocations will be happening in that
stray THD context

It was used only temporary, during udf_handler::fix_fields() time,
and then copied to the owner Item_func_or_sum object.
Changing the code to use the Used_tables_and_const_cache part
of the owner Item_sum_or_func object directly.

mariadb-service-convert during migration can create a file containing
ExecStartPre=/usr/sbin/sysctl -q -w vm.drop_caches=3 if the users my.cnf
contains [mysqld_safe] flush_caches. This sysctl entry change requires root
access. No existing ExecStartPre requires execution requires execution
as another user.

There is a comment in the mariadb{,@}.service.in that indicates
mysqld_install which would require -u mysql to explicity change user to
mysql from root since PermissionsStartOnly=true.

Otherwise the following error would be generated:
Oct 14 07:38:38 spaceman systemd[1]: Starting MariaDB database server...
-- Subject: Unit mariadb.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit mariadb.service has begun starting up.
Oct 14 07:38:38 spaceman sysctl[10089]: sysctl: permission denied on key 'vm.drop_caches'
Oct 14 07:38:38 spaceman systemd[1]: mariadb.service: control process exited, code=exited status=255
Oct 14 07:38:38 spaceman systemd[1]: Failed to start MariaDB database server.

Systemd config files need absolute paths.

LimitCore was ment to be LimitCORE

Oct 14 07:28:04 spaceman systemd[1]: [/etc/systemd/system/mariadb.service.d/migrated-from-my.cnf-settings.conf:7] Unknown lvalue 'LimitCore' in section 'Service'
Oct 14 07:28:04 spaceman systemd[1]: [/etc/systemd/system/mariadb.service.d/migrated-from-my.cnf-settings.conf:9] Executable path is not absolute, ignoring: sync
Oct 14 07:28:04 spaceman systemd[1]: [/etc/systemd/system/mariadb.service.d/migrated-from-my.cnf-settings.conf:10] Executable path is not absolute, ignoring: sysctl -q -w vm.drop_caches=3

During the review process OPTIONS was converted to MYSQLD_OPTS.
In the script mariadb-service convert, the ExecStart of the system
also uses this setting.

Since MariaDB packages have absolute paths, they are marked as not relocatable
by setting CPACK_RPM_PACKAGE_RELOCATABLE. According to logics of recent CPackRPM
it is not enough: one needs to set CPACK_PACKAGE_RELOCATABLE additionally.

After review/QA fixes.

Problem:
Procedure which uses stack of views first executed without most deep view.
It fails but one view cached (as well as whole procedure).
Then simultaniusely create the second view we lack and execute the procedure.
In the beginning of procedure execution the view is not yet created so
procedure used as it was cached (cache was not invalidated).
But by the time we are trying to use most deep view it is already created.
The problem with the view is that thd->select_number (first view was not parsed) so second view will get the same number.

The fix is in keeping the thd->select_number correct even if we use cached views.
In the proposed solution (to keep it simple) counter can be bigger then should but it should not create problem because numbers are still unique and situation is very rare.