to wrong result
      
When using MIXED mode and issuing 'CREATE TEMPORARY TABLE t_tmp',
the statement is logged if the current binlogging mode is
STATEMENT. This causes the slave to replay the instruction and
create the temporary table as well. If there is no switch to ROW
mode, and later on a 'DROP TEMPORARY TABLE t_tmp' is issued, then
this statement will also be logged and the slave will
remove/close the temporary table.
      
However, if there is a switch to ROW mode between the CREATE and
DROP TEMPORARY table, the DROP statement will not be logged,
leaving the slave with a dangling temporary table.
      
This patch addresses this, by always logging a DROP TEMPORARY
TABLE IF EXISTS when in mixed mode and a drop statement is issued
for temporary table(s).

mysqld

The problem was that enabling the event scheduler inside a init
file caused the server to crash upon start-up. The crash occurred
because the event scheduler wasn't being initialized before the
commands in the init-file are processed.

The solution is to initialize the event scheduler before the init
file is read. The patch also disables the event scheduler during
bootstrap and makes the bootstrap operation robust in the
presence of background threads.

mysqld

******
manual merge 5.0-bugteam --> 5.1-bugteam (bug 38816)

            procedures causes crashes!

The problem of that bugreport was mostly fixed by the
patch for bug 38691.
However, attached test case focused on another crash or
valgrind warning problem: SHOW PROCESSLIST query accesses
freed memory of SP instruction that run in a parallel
connection.

Changes of thd->query/thd->query_length in dangerous
places have been guarded with the per-thread
LOCK_thd_data mutex (the THD::LOCK_delete mutex has been
renamed to THD::LOCK_thd_data).

In create_myisam_from_heap() mark all errors as fatal except 
HA_ERR_RECORD_FILE_FULL for a HEAP table.

Not doing so could lead to problems, e.g. in a case when a
temporary MyISAM table gets overrun due to its MAX_ROWS limit
while executing INSERT/REPLACE IGNORE ... SELECT. 
The SELECT execution was aborted, but the error was 
converted to a warning due to IGNORE clause, so neither 'ok' 
nor 'error' packet could be sent back to the client. This 
condition led to hanging client when using 5.0 server, or 
assertion failure in 5.1.

Problem was that a failing rename just left the partitions at the state
it was at the failure.

Solution was to try to revert the started rename if a failure occured.

"WL#4584 New euckr characters" from 5.4.
(as agreed on ServerPT meeting on July 8).

not logged
        
Errors encountered during initialization of the SSL subsystem
are printed to stderr, rather than to the error log.
        
This patch adds a parameter to several SSL init functions to
report the error (if any) out to the caller. The function
init_ssl() in mysqld.cc is moved after the initialization of
the log subsystem, so that any error messages can be logged to
the error log. Printing of messages to stderr has been 
retained to get diagnostic output in a client context.

binlog
      
The fix for BUG 43929 introduced a regression issue. In a nutshell, when a
statement that changes a non-transactional table fails, it is written to the
binary log with the error code appended. Unfortunately, after BUG 43929, this
failure was flushing the transactional chace causing mismatch between execution
and logging histories. To fix this issue, we avoid flushing the transactional
cache when a commit or rollback is not issued.

When during the optimization an item is moved to the upper select
the item's context left unchanged. This caused wrong result in the 
PS/SP mode.
The Item_ident::remove_dependence_processor now sets the context
of the select to which the item is moved to.

                    it returns misleading 'table is full'

Innodb returns a misleading error message "table is full" 
when the number of active concurrent transactions is greater
than 1024.

Fixed by adding errorcode "ER_TOO_MANY_CONCURRENT_TRXS" to the
error codes. Innodb should return HA_TOO_MANY_CONCURRENT_TRXS
to mysql which is then mapped to ER_TOO_MANY_CONCURRENT_TRXS


Note: testcase is not written as this was reproducible only by
      changing innodb code.

Append the patch for resolving the problems, which have been brought by commiting bug#45214.

In a subselect all fields from outer selects are marked as dependent on
selects they are belong to. In some cases optimizer substitutes it for an
equivalent expression. For example "a_field IN (SELECT outer_field)" is
substituted with "a_field = outer_field". As we moved the outer_field to the
upper select it's not really outer anymore. But it was left marked as outer.
If exists an index over a_field optimizer choose wrong execution plan and thus
return wrong result.

Now the Item_in_subselect::single_value_transformer function removes dependent
marking from fields when a subselect is optimized away.

       
Fixed various compilation warnings when compiling on a 
 64 bit windows.