The test started failing on the same day patch for BUG 49978 was
pushed. BUG 49978 changed part of the replication testing
infrastructure in mysql-test-run. This caused the test to fail
sporadically with result differences on relay log file
names. When the test fails the relay-log filenames are shifted by
one, eg:

-show relaylog events in 'slave-relay-bin.000002' from <binlog_start>;
+show relaylog events in 'slave-relay-bin.000003' from <binlog_start>;

The problem was caused by a bad cleanup when using the include
files:

  - include/setup_fake_relay_log.inc
  - include/cleanup_fake_relay_log.inc

Which would leave a spurious relay-log file around (not listed in
slave-relay-bin.index), causing the server to shift the name of
the relay logs by one, even if cleaning up with RESET SLAVE.

We fix this by removing the relay-log file when it is not needed
anymore, ie at setup time and after recreating the fake relay-log
index.

Additionally, to make the affected test more resilient, we
deployed a call to rpl_reset.inc (which resets both master and
slave, including log files) before actually running the test
case.

Finally, appart from the reported bug, we also fix: (a) an
unrelated issue with the failing test itself - in some cases, the
test was not setting the log file name to use when it should; 
(b) one typo.

tmptable needed

The function DEFAULT() works by modifying the the data buffer pointers (often
referred to as 'record' or 'table record') of its argument. This modification
is done during name resolution (fix_fields().) Unfortunately, the same
modification is done when creating a temporary table, because default values
need to propagate to the new table.

Fixed by skipping the pointer modification for fields that are arguments to
the DEFAULT function.

if max_allowed_packet >= 16M.

This bug was introduced by patch for bug#42503.

This patch restores behaviour that there was before patch
for bug#42503 was applied.

The problem from a user point of view was that on Solaris the
time related functions (e.g. NOW(), SYSDATE(), etc) would always
return a fixed time.

This bug was happening due to a logic in the time retrieving
wrapper function which would only call the time() function every
half second. This interval between calls would be calculated
using the gethrtime() and the logic relied on the fact that time
returned by it is monotonic.

Unfortunately, due to bugs in the gethrtime() implementation,
there are some cases where the time returned by it can drift
(See Solaris bug id 6600939), potentially causing the interval
calculation logic to fail.

The solution is to retrieve the correct time whenever a drift in
the time returned by gethrtime() is detected. That is, do not
use the cached time whenever the values (previous and current)
returned by gethrtime() are not monotonically increasing.

extended' to crash mysqld" (see http://lists.mysql.com/commits/128409).

to crash mysqld". 
      
handler::pushed_cond was not always properly reset when table objects where
recycled via the table cache.
      
handler::pushed_cond is now set to NULL in handler::ha_reset(). This should 
prevent pushed conditions from (incorrectly) re-apperaring in later queries.

and 'THREAD_SAFE_CLIENT'.
  
As of MySQL 5.5, we no longer support non-threaded
builds.   This patch removes all references to the
obsolete THREAD and THREAD_SAFE_CLIENT preprocessor
symbols.  These were used to distinguish between
threaded and non-threaded builds.

Remove the test from defaults.experimental.

          the my.cnf, works as command
      
Different parsing mechanisms are used for command line/my.cnf 
options  and the SQL commands.  The former only accepted
numeric arguments, and regarded all numbers different from 0 
as 'true'.  Any other argument was parsed as 'false' .
      
This patch adds the words 'true' and 'on' as valid truth
values for boolean option arguments.
      
A test case is not provided, as the fix is simple and
does not warrant a separate test file (no existing
suitable test file was found)

(backported from mysql-trunk)

           OPTIMIZE TABLE

OPTIMIZE TABLE for InnoDB tables is handled as recreate + analyze.
The triggered assert checked that an error had been reported if either
recreate or analyze failed. However the assert failed to take into
account that they could have failed because OPTIMIZE TABLE had been
victim of KILL QUERY, KILL CONNECTION or server shutdown.

This patch adjusts the assert to take this possibility into account.
The problem was only noticeable on debug versions of the server.

Test case added to innodb_mysql_sync.test.

          and Order By
      
When having a UNION statement in a subquery, with no
referenced tables (or only a reference to the virtual
table 'dual'), the UNION did not allow an ORDER BY clause.
      
      i.e:
          SELECT(SELECT 1 AS a UNION 
                 SELECT 0 AS a 
                 ORDER BY a) AS b  or
          SELECT(SELECT 1 AS a FROM dual UNION 
                 SELECT 0 as a 
                 ORDER BY a) AS b
      
      
In addition, an ORDER BY / LIMIT clause was not accepted
in subqueries even for single SELECT statements with no 
referenced tables (or with 'dual' as table reference)
      
   i.e: 
      SELECT(SELECT 1 AS a ORDER BY a) AS b  or
      SELECT(SELECT 1 AS a FROM dual ORDER BY a) AS b
      
The fix was to allow an optional ORDER BY/LIMIT clause to
the grammar for these cases.
      
See also: Bug#57986

          if embedded in a SELECT
            
An ORDER BY clause was bound to the incorrect
(sub-)statement when used in a UNION context.
            
In a query like:
SELECT * FROM a UNION SELECT * FROM b ORDER BY c
the result of SELECT * FROM b is sorted, and then
combined with a.  The correct behaviour is that
the ORDER BY clause should be applied on the
final set.   Similar behaviour was seen on LIMIT
clauses as well.
            
In a UNION statement, there will be a select_lex
object for each of the two selects, and a 
select_lex_unit object that describes the UNION
itself.  Similarly, the same behaviour was also
seen on derived tables.
            
The bug was caused by using a grammar rule for
ORDER BY and LIMIT that bound these elements
to thd->lex->current_select, which points to the
last of the two selects, instead of to the 
fake_select_lex member of the master select_lex_unit
object.

(irrelevant for 5.5 and up)

InnoDB Plugin 1.0.14 has been released with MySQL 5.1.54.

Truncate the maximum result length (64-bit wide type) to fit into
the item maximum length (32-bit wide type). This is possible as
this specific branch is only used if the maximum result length
is less than 0x1000000 (MAX_BLOB_WIDTH), which fits comfortably
in a 32-bit wide type.

WIN32 compilation fixes: define ETIMEDOUT only if not available and
fix typos and add a missing parameter.

From a user perspective, the problem is that a FLUSH LOGS or SIGHUP
signal could end up associating the stdout and stderr to random
files. In the case of this bug report, the streams would end up
associated to InnoDB ibd files.

The freopen(3) function is not thread-safe on FreeBSD. What this
means is that if another thread calls open(2) during freopen()
is executing that another thread's fd returned by open(2) may get
re-associated with the file being passed to freopen(3). See FreeBSD
PR number 79887 for reference:

  http://www.freebsd.org/cgi/query-pr.cgi?pr=79887

This problem is worked around by substituting a internal hook within
the FILE structure. This avoids the loss of atomicity by not having
the original fd closed before its duplicated.

Patch based on the original work by Vasil Dimov.

This change is relevant only for 5.1.

Do not use nested AC_CHECK_FUNC() because they result in:

./configure: line 52688: syntax error: unexpected end of file

(which happens only on some platforms and does not happen on others,
I have no idea what is the reason for this)

   Basically take care that disconnects are finished.

- Second scenario checked:
  Ensure via wait routines that the commit comes after the
  processing of the statement which should get finally
  the ER_LOCK_WAIT_TIMEOUT
  --> This should prevent the current bug.
- First scenario checked:
  Ensure via wait routines that the statement is already waiting
  for getting the lock before the commit is given.
  --> No effect on the current bug, but ensure that the right
      scenario is reached.
- Take care that disconnects are finished before the test ends.
  --> Reduce the potential to harm succeeding tests.
- "Mangle" the printout of the current default innodb_lock_wait_timeout value
  --> No need to adjust the test in case the default gets changed in future.

   - remove the superfluous file
   - add an preemptive removal of the outfile before the
     SELECT ... INTO OUTFILE ...
2. Remove an already disabled subtest
   It's functionality is covered by tests in the suite funcs_1.
3. Adjust the formatting within some sub testcase to the formatting used
   in all other sub testcases

This is a null-merge because Bug#59327 is present only in 5.1