If using statement based replication (SBR), repeatedly calling
statements which are unsafe for SBR will cause a warning message
to be written to the error for each statement. This might lead
to filling up the error log and there is no way to disable this
behavior.

The solution is to only log these message (about statements unsafe
for statement based replication) if the log_warnings option is set.

For example:

SET GLOBAL LOG_WARNINGS = 0;
INSERT INTO t1 VALUES(UUID());
SET GLOBAL LOG_WARNINGS = 1;
INSERT INTO t1 VALUES(UUID());

In this case the message will be printed only once:

[Warning] Statement may not be safe to log in statement format.
          Statement: INSERT INTO t1 VALUES(UUID())

Initialize LOCK_open as a adapative mutex on platforms where the
PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP macro is available. The flag
indicates that a thread should spin (busy wait) for some time on a
locked adaptive mutex before blocking (sleeping). It's intended to
to alleviate performance problems due to LOCK_open being a highly
contended mutex.

      
A REPLACE in the MERGE engine is actually a REPLACE
into one (FIRST or LAST) of the underlying MyISAM
tables. So in effect the server works on the meta
data of the MERGE table, while the real insert happens
in the MyISAM table.

The MERGE table has no index, while MyISAM has a
unique index. When a REPLACE into a MERGE table (
and the REPLACE conflicts with a duplicate in a
child table) is done, we try to access the duplicate
key information for the MERGE table. This information
actually does not exist, hence this results in a crash.

The problem can be resolved by modifying the MERGE
engine to provide us the duplicate key information
directly, instead of just returning the MyISAM index
number as the error key. Then the SQL layer (or "the
server") does not try to access the key_info of the
MERGE table, which does not exist.

The current patch modifies the MERGE engine to provide
the position for a record where a unique key violation
occurs.

Fixed wrong prototype declaration which cased build failure on solaris.

          an assertion in a debug build.

The reason is that the C API doesn't support multiple result sets for prepared
statements and attempting to execute a stored routine which returns multiple result
sets sometimes lead to a network error. The network error sets the diagnostic area
prematurely which later leads to the assert when an attempt is made to set a second
server state.

This patch fixes the issue by changing the scope of the error code returned by
sp_instr_stmt::execute() to include any error which happened during the execution.
To assure that Diagnostic_area::is_sent really mean that the message was sent all
network related functions are checked for return status.

Bug#46354, when defining partitions without subpartition definition after defining it with the first partition and using list partition caused crash, fixed by more error checks in parser

those keywords do nothing in 5.1 (they are meant for future versions, for example featuring the Maria engine)
so they are here removed from the syntax. Adding those keywords to future versions when needed is:
- WL#5034 "Add TRANSACTIONA=0|1 and PAGE_CHECKSUM=0|1 clauses to CREATE TABLE"
- WL#5037 "New ROW_FORMAT value for CREATE TABLE: PAGE"

consumption (CPU) for upgrading a large log table can be intense.
Therefore, truncate the general_log table beforehand if running
mysql_upgrade test with Valgrind.

            compression 
 
Since uint3korr() may read 4 bytes depending on build flags and 
platform, allocate 1 extra "safety" byte in the network buffer 
for cases when uint3korr() in my_real_read() is called to read
last 3 bytes in the buffer. 
 
It is practically hard to construct a reliable and reasonably 
small test case for this bug as that would require constructing 
input stream such that a certain sequence of bytes in a 
compressed packet happens to be the last 3 bytes of the network 
buffer. 

If the log_bin_trust_function_creators option is not defined, creating a stored
function requires either one of the modifiers DETERMINISTIC, NO SQL, or READS
SQL DATA. Executing a stored function should also follows the same rules if in
STATEMENT mode. However, this was not happening and a wrong error was being
printed out: ER_BINLOG_ROW_RBR_TO_SBR.

The patch makes the creation and execution compatible and prints out the correct
error ER_BINLOG_UNSAFE_ROUTINE when a stored function without one of the modifiers
above is executed in STATEMENT mode.

The maximum value of the max_join_size variable is set by converting
a signed type (long int) with negative value (-1) to a wider unsigned
type (unsigned long long), which yields the largest possible value of
the wider unsigned type -- as per the language conversion rules. But,
depending on build options, the type of the max_join_size might be a
shorter type (ha_rows - unsigned long) which causes the warning to be
thrown once the large value is truncated to fit.

The solution is to ensure that the maximum value of the variable is
always set to the maximum value of integer type of max_join_size.

Furthermore, it would be interesting to always have a fixed type for
this variable, but this would incur in a change of behavior which is
not acceptable for a GA version. See Bug#35346.

during bootstrap on a embedded server.

Post-merge fix: test case could fail due to a conversion of the
max_join_size value to a integer. Fixed by preserving the value
as a string for comparison purposes.

One of the tests introduced for this bug was failing 
because of path size restriction in windows.
Moved the test case to a new test which is disabled under windows.

           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).