In some circumstances, when a table is created with
the IBMDB2I engine, the CREATE TABLE statement will
return successfully but the table will not exist.

The current patch addresses the above issue and causes
CREATE to fail and report and error to the user.

Bug#44091: libmysqld gets stuck waiting on mutex on initialization

The problem was that libmysqld wasn't enforcing a certain
initialization and deinitialization order for the mysys
library. Another problem was that the global object used
for management of log event handlers (aka LOGGER) wasn't
being prepared for a possible reutilization.

What leads to the hang/crash reported is that a failure
to load the language file triggers a double call of the
cleanup functions, causing an already destroyed mutex to
be used.

The solution is enforce a order on the initialization and
deinitialization of the mysys library within the libmysqld
library and to ensure that the global LOGGER object reset
it's internal state during cleanup.

Note: empty changeset.

routine does not exist 
      
There is an inconsistency with DROP DATABASE IF EXISTS, DROP TABLE IF
EXISTS and DROP VIEW IF EXISTS: those are binlogged even if the DB or
TABLE does not exist, whereas DROP PROCEDURE IF EXISTS does not. It
would be nice or at least consistent if DROP PROCEDURE/STATEMENT
worked the same too.
      
Fixed DROP PROCEDURE|FUNCTION IF EXISTS by adding a call to
mysql_bin_log.write in mysql_execute_command. Checked also if all 
documented "DROP (...) IF EXISTS" get binlogged.
      
NOTE: This is a 5.0 backport patch as requested by support.

The crash happens due to wrong 'digits' variable value(0),
'digits' can not be 0, so the fix is use 1 as min allowed value.

            
Currently the memory map is being created
with a size that is greater than the size 
of the underlying datafile. This can cause
varying behaviour,

e.g. 

In windows the size of the datafile
is increased, while on linux it remains
the same.

This fix removes the increment margin to
the size that is used while creating the
memory map.

Binlog the CREATE EVENT unless the created event been successfully dropped

Modified Query_log_event constructor to make sure that error_code
is not set to ER_SERVER_SHUTDOWN or ER_QUERY_INTERRUPTED errors
when NOT_KILLED

The result set for multi-row statements is not the same between STMT and
RBR and among different versions. Thus to avoid test failures, we are not
printing out such result sets. Note, however, that this does not have
impact on coverage and accuracy since the execution is able to continue
without further issues when an error is found on the master and such error
is set to be skipped.

While printing the Max keyfile length 'llstr' call was used which 
was treating the max_key_file_length as negative.

Changing this to ullstr fixes the problem. 
myisamchk output will differ in 32 bit and 64 bit Operating systems 
so its not possible to have test case for this bug.

The conformance checker was not taking into
account, and, making concessions for acceptable
incompatibilites in tables created by
versions earlier than 4.1.

The current patch relaxes the conformance
checker to ignore differences in key_alg
and language for tables created by versions
earlier than 4.1.

      
The test started failing following the push for BUG#41541.
Some of the algorithms access bytes beyond the input data
and this can affect up to one byte less than "word size"
which is BITS_SAVED / 8. 
      
Fixed by adding (BITS_SAVED / 8) -1 bytes to buffer size
(i.e. Memory Segment #2) to avoid accessing un-allocated data.

The patch was originally proposed by Mikael and reviewed by Bar.

                              
RBR was not considering the option --slave-skip-errors.
                              
To fix the problem, we are reporting the ignored ERROR(s) as warnings thus avoiding 
stopping the SQL Thread. Besides, it fixes the output of "SHOW VARIABLES LIKE 
'slave_skip_errors'" which was showing nothing when the value "all" was assigned 
to --slave-skip-errors.
                  
@sql/log_event.cc
  skipped rbr errors when the option skip-slave-errors is set.
@sql/slave.cc
  fixed the output of for SHOW VARIABLES LIKE 'slave_skip_errors'"
@test-cases
  fixed the output of rpl.rpl_idempotency
  updated the test case rpl_skip_error

1. Test case was rewritten completely.
2. Test covers 3 cases:
 a) do deadlock on slave, wait retries of transaction, unlock slave before lock
timeout;
 b) do deadlock on slave and wait error 'lock timeout exceed' on slave;
 c) same as b) but if of max relay log size = 0;
3. Added comments inline.
4. Updated result file.

The problem is that a SELECT .. FOR UPDATE statement might open
a table and later wait for a impeding global read lock without
noticing whether it is holding a table that is being waited upon
the the flush phase of the process that took the global read
lock.

The same problem also affected the following statements:

LOCK TABLES .. WRITE
UPDATE .. SET (update and multi-table update)
TRUNCATE TABLE ..
LOAD DATA ..

The solution is to make the above statements wait for a impending
global read lock before opening the tables. If there is no
impending global read lock, the statement raises a temporary
protection against global read locks and progresses smoothly
towards completion.

Important notice: the patch does not try to address all possible
cases, only those which are common and can be fixed unintrusively
enough for 5.0.