Field_time::get_time() did not initialize some members of 
MYSQL_TIME which led to valgrind warnings when those members 
were accessed in Protocol_simple::store_time(). 
 
It is unlikely that this bug could result in wrong data 
being returned, since Field_time::get_time() initializes the 
'day' member of MYSQL_TIME to 0, so the value of 'day' 
in Protocol_simple::store_time() would be 0 regardless 
of the values for 'year' and 'month'.

mysql-test/r/type_time.result:
  Added a test case for bug #44792.
mysql-test/t/type_time.test:
  Added a test case for bug #44792.
sql/field.cc:
  Field_time::get_time() did not initialize some members of 
  MYSQL_TIME which led to valgrind warnings when those members 
  were accessed in Protocol_simple::store_time().

In UNION if we use last SELECT without braces and this
SELECT have ORDER BY clause, such clause belongs to
global UNION. It is parsed like last SELECT
part and used further as 'unit->global_parameters->order_list' value.
During DESCRIBE EXTENDED we call select_lex->print_order() for
last SELECT where order fields refer to tmp table 
which already freed. It leads to crash.
The fix is clean up global_parameters->order_list
instead of fake_select_lex->order_list.


mysql-test/r/union.result:
  test result
mysql-test/t/union.test:
  test case
sql/sql_union.cc:
  In UNION if we use last SELECT without braces and this
  SELECT have ORDER BY clause, such clause belongs to
  global UNION. It is parsed like last SELECT
  part and used further as 'unit->global_parameters->order_list' value.
  During DESCRIBE EXTENDED we call select_lex->print_order() for
  last SELECT where order fields refer to tmp table 
  which already freed. It leads to crash.
  The fix is clean up global_parameters->order_list
  instead of fake_select_lex->order_list.

  UNIX sockets need to be on a path shorter than 70 characters on some older platofrms.
  MTRv1 tries to fix this by moving the socket to the $TMPDIR, however this causes
  issues with certain tests on Windows.

  Fixed by not applying any hacks on Windows - Windows does not need them.

It is not possible to prevent the server from starting if a mandatory
built-in plugin fails to start. This can in some cases lead to data
corruption when the old table name space suddenly is used by a different
storage engine.

A boolean command line option in the form of --foobar is automatically
created for every existing plugin "foobar". By changing this command line
option from a boolean to a tristate { OFF, ON, FORCE } it is possible to
specify the plugin loading policy for each plugin.

The behavior is specified as follows:
   OFF   = Disable the plugin and start the server
   ON    = Enable the plugin and start the server even if an error occurrs
           during plugin initialization.
   FORCE = Enable the plugin but don't start the server if an error occurrs
           during plugin initialization.


mysql-test/lib/mtr_cases.pm:
  * Changed --<pluginname> from a boolean to a tristate.
mysys/my_getopt.c:
  * Changed --<pluginname> from boolean to tristate. Optional arguments
    must still work for tristates. It is praxis that disable means value 0
    and enable is value 1. Since plugin name is the only tristate with
    optional arguments this principle will still hold.
sql/sql_plugin.cc:
  * Changed --<pluginname> option from a boolean type to a tristate.
    - FORCE will now terminate the server if the plugin fails to
      initialize properly.
  * Refactored prototypes for test_plugin_options() and construct_options()
    to get rid of the 'enable' value pointer.
  * Cleaned up code related to option name constructing.
  * Added documentation
sql/sql_plugin.h:
  * Introduced new member to st_plugin_int structure.

UNIX sockets need to be on a path shorter than 70 characters on some older platofrms.
MTRv1 tries to fix this by moving the socket to the $TMPDIR, however this causes
issues with certain tests on Windows.

Fixed by not applying any hacks on Windows - Windows does not need them.

checking in a test case that will reproduce
the error on v5r4.

mysql-test/suite/ibmdb2i/include/have_i54.inc:
  Bug#44232 Error msg should be improved when collation not supported.
mysql-test/suite/ibmdb2i/r/ibmdb2i_bug_44232.result:
  Bug#44232 Error msg should be improved when collation not supported.
mysql-test/suite/ibmdb2i/t/ibmdb2i_bug_44232.test:
  Bug#44232 Error msg should be improved when collation not supported.

This patch fixes compilation warning, "conversion from 'time_t' to 'ulong', 
possible loss of data". 
The fix is to typecast time_t to ulong before assigning it to ulong. 
Backported this from 6.0-bugteam tree.


storage/archive/ha_archive.cc:
  type casting time_t to ulong before assigning.
storage/federated/ha_federated.cc:
  type casting time_t to ulong before assigning.
storage/innobase/handler/ha_innodb.cc:
  type casting time_t to ulong before assigning.
storage/myisam/ha_myisam.cc:
  type casting time_t to ulong before assigning.

            SQL_SELECT::test_quick_select

The crash was caused by an incomplete cleanup of JOIN_TAB::select
during the filesort of rows for GROUP BY clause inside a subquery.
Queries where a quick index access is replaced with filesort was
was affected. For example:

  SELECT 1 FROM
    (SELECT COUNT(DISTINCT c1) FROM t1
       WHERE c2 IN (1, 1) AND c3 = 2 GROUP BY c2) x

Quick index access related data in the SQL_SELECT::test_quick_select
function was inconsistent after an incomplete cleanup.
This function has been completed to prevent crashes in the
SQL_SELECT::test_quick_select function.


mysql-test/include/mix1.inc:
  Add test case for bug #44290.
mysql-test/r/innodb_mysql.result:
  Add test case for bug #44290.
sql/sql_select.cc:
  Bug #44290: explain crashes for subquery with distinct in
              SQL_SELECT::test_quick_select
  
  Quick index access related data in the SQL_SELECT::test_quick_select
  function was inconsistent after an incomplete cleanup.
  This function has been completed to prevent crashes in the
  SQL_SELECT::test_quick_select function.

"freeing items"

The calculation of the table map log event in the event constructor
was one byte shorter than what would be actually written. This would
lead to a mismatch between the number of bytes written and the event
end_log_pos, causing bad event alignment in the binlog (corrupted
binlog) or in the transaction cache while fixing positions
(MYSQL_BIN_LOG::write_cache). This could lead to impossible to read
binlog or even infinite loops in MYSQL_BIN_LOG::write_cache.

This patch addresses this issue by correcting the expected event
length in the Table_map_log_event constructor, when the field metadata
size exceeds 255.

sql/log_event.cc:
  Added the extra byte as net_store_length imposes.

Problem: using LOAD_FILE() in some cases we pass a file name string
without a trailing '\0' to fn_format() which relies on that however.
That may lead to valgrind warnings.

Fix: add a trailing '\0' to the file name passed to fn_format().


mysql-test/r/func_str.result:
  Fix for bug#44774: load_file function produces valgrind warnings
    - test result.
mysql-test/t/func_str.test:
  Fix for bug#44774: load_file function produces valgrind warnings
    - test case.
sql/item_strfunc.cc:
  Fix for bug#44774: load_file function produces valgrind warnings
    - passing a file name to fn_format(), file_name->c_ptr() replaced
      with file_name->c_ptr_safe() to ensure we have a trailing '\0'.

The problem is that the internal variable used to specify a
transaction with consistent read was being used outside the
processing context of a START TRANSACTION WITH CONSISTENT
SNAPSHOT statement. The practical consequence was that a
consistent snapshot specification could leak to unrelated
transactions on the same session.

The solution is to ensure a consistent snapshot clause is
only relied upon for the START TRANSACTION statement.

This is already fixed in a similar way on 6.0.

mysql-test/r/consistent_snapshot.result:
  Add test case result for Bug#44664
mysql-test/t/consistent_snapshot.test:
  Add test case for Bug#44664
sql/sql_parse.cc:
  The WITH CONSISTENT SNAPSHOT clause is only valid for the
  START TRANSACTION statement.

      
In the output from mysqlbinlog, incident log events were
represented as just a comment. Since the incident log event
represents an incident that could cause the contents of the
database to change without being logged to the binary log,
it means that if the SQL is applied to a server, it could
potentially lead to that the databases are out of sync.

In order to handle that, this patch adds the statement "RELOAD
DATABASE" to the SQL output for the incident log event. This will
require a DBA to edit the file and handle the case as apropriate
before applying the output to a server.

mysql-test/suite/binlog/t/binlog_incident-master.opt:
  Options file to cause server to generate an incident log
  event when executing a REPLACE.
mysql-test/suite/binlog/t/binlog_incident.test:
  Test to check that the incident log event is represented
  correctly in the output from mysqlbinlog.
sql/log_event.cc:
  The incident log event now ouput a "RELOAD DATABASE" instead
  of just a comment. RELOAD DATABASE is not an existing command
  and will generate a syntax error.

Problem: storing "SELECT ... INTO @var ..." results in variables we used val_xxx()
methods which returned results of the current row. 
So, in some cases (e.g. SELECT DISTINCT, GROUP BY or HAVING) we got data
from the first row of a new group (where we evaluate a clause) instead of
data from the last row of the previous group.

Fix: use val_xxx_result() counterparts to get proper results.


mysql-test/r/distinct.result:
  Fix for bug#42009: SELECT into variable gives different results to direct SELECT
    - results adjusted.
mysql-test/r/user_var.result:
  Fix for bug#42009: SELECT into variable gives different results to direct SELECT
    - test result.
mysql-test/t/user_var.test:
  Fix for bug#42009: SELECT into variable gives different results to direct SELECT
    - test case.
sql/item_func.cc:
  Fix for bug#42009: SELECT into variable gives different results to direct SELECT
    - Item_func_set_user_var::save_item_result() added to evaluate and store 
      an item's result into a user variable.
sql/item_func.h:
  Fix for bug#42009: SELECT into variable gives different results to direct SELECT
    - Item_func_set_user_var::save_item_result() added to evaluate and store 
      an item's result into a user variable.
sql/sql_class.cc:
  Fix for bug#42009: SELECT into variable gives different results to direct SELECT
    - use Item_func_set_user_var::save_item_result() to store results into user 
      variables.