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

Mysql server crashes because unsafe statements warning is wrongly elevated to error,
which is set the error status of Diagnostics_area of the thread in THD::binlog_query().
Yet the caller believes that binary logging shouldn't touch the status, so it will
set the status also later by my_ok(), my_error() or my_message() seperately
according to the execution result of the statement or transaction.
But the status of Diagnostics_area of the thread is allowed to set only once.

Fixed to clear the error wrongly set by binary logging, but keep the warning message.

Fix belonging to bug#42838: Though this bug is only for 6.0 I put in some updated result files for 6.0 and this are the corrsponding resul files for 5.1, so that sys_vars should then run successfully also in 5.1.

Altered the test to accommodate the new behavior of max_allowed_packet.
Had to disconnect / reconnect the default connection for the new value to register.
Re-enabled certain parts of the test that were commented out and added
some setup / cleanup code to ensure proper reset of max_allowed_packet at the end of the test.

Re-recorded the .result file to account for changes to the test.

Bug#32136: mysqld_multi --defaults-file not respected while using \
	--mysqld=mysqld_safe

Revert change that adds "--no-defaults" to mysqld_multi.

This closes Bug#43508 and re-opens Bug#32136.

It was a test case problem: one 'reap' statement was forgotten.