to allow temp table operations) -- prerequisite patch #2.

Introduce a new form of find_temporary_table() function:
find_temporary_table() by a table key. It will be used
in further patches.

Replace find_temporary_table(table_list->db, table_list->name)
by more appropiate find_temporary_table(table_list) across
the codebase.

from 5.1.50 to 5.5.6".

Debug builds of the server aborted due to an assertion
failure when DROP DATABASE statement was run on an
installation which had outdated or corrupt mysql.proc table.
Particularly this affected the mysql_upgrade tool which is
run as part of 5.1 to 5.5 upgrade.

The problem was that sp_drop_db_routines(), which was invoked
during dropping of the database, could have returned without
closing and unlocking mysql.proc table in cases when this
table was not up-to-date with the current server. As a result
further attempt to open and lock the mysql.event table, which
was necessary to complete dropping of the database, ended up
with an assert.

This patch solves this problem by ensuring that
sp_drop_db_routines() always closes mysql.proc table and
releases metadata locks on it. This is achieved by changing
open_proc_table_for_update() function to close tables and
release metadata locks acquired by it in case of failure.
This step also makes behavior of the latter function
consistent with behavior of open_proc_table_for_read()/
open_and_lock_tables().


Test case for this bug was added to sp-destruct.test.

to allow temp table operations) -- prerequisite patch #1.
  
Move a piece of code that initialiazes TABLE instance
after it was successfully opened into a separate function.
This function will be reused in the following patches.

This assert could be triggered if ALTER EVENT failed to load the
event after altering it. Failing to load the event could for 
example happen because of KILL QUERY.

The assert tested that the result of a failed load_named_event()
was OP_LOAD_ERROR. However since load_named_event() returns bool,
this assert did not make any sense. This patch therefore removes
the assert, fixing the problem. The patch also removes 
enum_events_error_code since it was unused.

No test case added. The bug fix is trivial and this bug was
easily detected by RQG tests. Further, adding a MTR test case
for this bug would require adding sync points to make the
test case repeatable.

The 'mysqlhotcopy' tool gets into bin/ directory after the installation
from the scripts/.
So check for it in that in the mysql-test-run.pl.

per-file comments:
  mysql-test/mysql-test-run.pl
Check the bin/ for mysqlhotcopy presence.

Updated the result files for ndb test cases.

Parts that aren't supposed to work on Windows moved to the separate
mysql_not_windows.test.

doing LOCK TABLE+INSERT DELAYED" from mysql-5.5-bugfixing
into mysql-5.5-runtime.

with two connections doing LOCK TABLE+INSERT DELAYED".

Disabled --ps-protocol for this part of the test as INSERT
DELAYED simply doesn't work with it under LOCK TABLES.

             LOCK TABLE+INSERT DELAYED

The problem was that the server could crash if the insert delayed
handler thread was killed due to a conflicting shared metadata
lock. This could happen because the metadata lock ticket was
added to the handler thread before it was properly initialized.

This patch moves the cloning of the acquired metadata lock ticket
until after the handler thread has been properly initialized.

Recording fixed correct results results.

The Item_cache_datetime::val_str function wasn't taking into account that time
could be negative. This led to failed assertion.
Now Item_cache_datetime::val_str correctly converts negative time values
from integer to string representation.

mysql-test/r/func_group.result:
  Added a test case for the bug#56120.
mysql-test/t/func_group.test:
  Added a test case for the bug#56120.
sql/item.cc:
  Bug#56120: Failed assertion on MIX/MAX on negative time value
  Now Item_cache_datetime::val_str correctly converts negative time values
  from integer to string representation.

The problem was that deadlocks involving INSERT DELAYED were not detected.

The reason for this is that two threads are involved in INSERT DELAYED:
the connection thread and the handler thread. The connection thread would
wait while the handler thread acquired locks and opened the table.
In essence, this adds an edge to the wait-for-graph between the 
connection thread and the handler thread that the deadlock detector is
unaware of. Therefore many deadlocks involving INSERT DELAYED were not 
detected.

This patch fixes the problem by having the connection thread acquire the
metadata lock the table before starting the handler thread. This allows the
deadlock detector to detect any possible deadlocks resulting from trying to
acquire a metadata lock the table. If a metadata lock is successfully acquired,
the handler thread is started and given a copy of the ticket representing the
metadata lock. When the handler thread then tries to lock and open the table,
it will find that it already has the metadata lock and therefore not acquire
any new metadata locks.

Test cases added to delayed.test.

      
Problem: ENUM columns are sorted and distributed according to their
numeric value, but Field::hash() incorrectly passed string character set
(utf32) in combination with numeric value to the hash function,
which made assertion fail.

Fix: pass "binary" character set in combination with numeric value
to the hash function.

  mysql-test/suite/parts/r/part_ctype_utf32.result
  Adding tests

  mysql-test/suite/parts/t/part_ctype_utf32.test
  Adding test

  sql/field.cc
  Pass correct character set pointer to the hash function.

The include/mysqlhotcopy.inc had an error in the 'if' condition, so it failed
if the mysqlhotcopy tool was found.

per-file comments:
  mysql-test/include/mysqlhotcopy.inc
        test should proceed exactly if the mysqlhotcopy was set.
  mysql-test/mysql-test-run.pl
        don't set the MYSQL_HOTCOPY variable if no mysqlhotcopy was found.

my_thread_global_end() now sets mysql_thread_basic_global_init_done= 0
to ensure destroyed mutexes are not reused.

I verified that clearing this flag will not result in the redundant allocation
of other resources allocated by my_thread_global_init() and
my_thread_basic_global_init().

mysys/my_thr_init.c:
  Clear mysql_thread_basic_global_init_done flag at the end of my_thread_global_end()

The ALTER PARTITION and SELECT seemed to be deadlocked
when having innodb_thread_concurrency = 1.

Problem was that there was unreleased latches
in the ALTER PARTITION thread which was needed
by the SELECT thread to be able to continue.

Solution was to release the latches by commit 
before requesting upgrade to exclusive MDL lock.

Updated according to reviewers comments (3).

mysql-test/r/partition_innodb.result:
  updated test result
mysql-test/t/partition_innodb.test:
  added test
sql/sql_partition.cc:
  Moved implicit commit into mysql_change_partition
  so that if latches are taken, they are always released
  before waiting on exclusive lock.
sql/sql_table.cc:
  refactored the code to prepare and commit
  around copy_data_between_tables, to be able
  to reuse it in mysql_change_partitions
sql/sql_table.h:
  exporting mysql_trans_prepare/commit_alter_copy_data

            attempt to install a plugin twice

Server crashes when [UN]INSTALL PLUGIN fails (returns an
error) and general log is disabled and there are audit
plugins interested in MYSQL_AUDIT_GENERAL_CLASS. 

When audit event is triggered, audit subsystem acquires interested
plugins by walking through plugin list. Evidently plugin list
iterator protects plugin list by acquiring LOCK_plugin, see
plugin_foreach_with_mask().

On the other hand [UN]INSTALL PLUGIN is acquiring LOCK_plugin
rather for a long time.

When audit event is triggered during [UN]INSTALL PLUGIN, plugin
list iterator acquires the same lock (within the same thread)
second time.

Repeatable only with general_log disabled, because general_log
triggers MYSQL_AUDIT_GENERAL_LOG event, which acquires audit
plugins before [UN]INSTALL PLUGIN acquired LOCK_plugin.

With this fix we pre-acquire audit plugins for events that
may potentially occur during [UN]INSTALL PLUGIN.

This hack should be removed when LOCK_plugin is fixed so it
protects only what it supposed to protect.

No test case for this fix - we do not have facility to test
audit plugins yet.

sql/sql_audit.cc:
  Move "acquire audit plugin" logics to a separate
  function.
sql/sql_audit.h:
  Move "acquire audit plugin" logics to a separate
  function.
sql/sql_plugin.cc:
  Pre-acquire audit plugins for events that may potentially occur
  during [UN]INSTALL PLUGIN.

was caused by change of thread state name from "Waiting for
table" to "Waiting for table metadata lock" (which has 
happened as part of fix for bug 52044 "FLUSH TABLES WITH READ
LOCK and FLUSH TABLES <list> WITH READ LOCK are incompati").

           on CREATE TABLE .. SELECT I_S.PART

This assert was triggered if an InnoDB table was created using
CREATE TABLE ... AS SELECT where the query used an I_S table, and
a view existed in the database. It would also be triggered for
any statement changing an InnoDB table (e.g. INSERT, UPDATE, DELETE)
which had a subquery referencing an I_S table.

The assert was triggered if open_normal_and_derived_tables() failed
and a statement transaction had been started. This will usually not
happen as tables are opened before a statement transaction is started.
However, e.g. CREATE TABLE ... AS SELECT starts a transaction in order
to insert tuples into the new table. And if the subquery references
an I_S table, all current tables and views can be opened in order to
fill the I_S table on the fly. If a view is discovered, open will fail
as it is instructed to open tables only (OPEN_TABLE_ONLY). This would
cause the assert to be triggered.

The assert was added in the patch for Bug#52044 and was therefore
not in any released versions of the server.

This patch fixes the problem by adjusting the assert to take into
consideration the possibility of tables being opened as part of
an I_S query. This is similar to what is already done for 
close_tables_for_reopen().

Test case added to information_schema_inno.test.

temp table
            
This patch introduces two key changes in the replication's behavior.
            
Firstly, it reverts part of BUG#51894 which puts any update to temporary tables
into the trx-cache. Now, updates to temporary tables are handled according to
the type of their engines as a regular table.
            
Secondly, an unsafe mixed statement, (i.e. a statement that access transactional
table as well non-transactional or temporary table, and writes to any of them),
are written into the trx-cache in order to minimize errors in the execution when
the statement logging format is in use.
            
Such changes has a direct impact on which statements are classified as unsafe
statements and thus part of BUG#53259 is reverted.

end_*_wait() functions now honor TIMER_STATE_UNTIMED

storage/perfschema/pfs.cc:
  Don't aggregate stats if TIMER_STATE_UNTIMED