Text conflict in mysql-test/collections/default.experimental
Text conflict in mysql-test/r/show_check.result
Text conflict in mysql-test/r/sp-code.result
Text conflict in mysql-test/suite/binlog/r/binlog_tmp_table.result
Text conflict in mysql-test/suite/rpl/t/disabled.def
Text conflict in mysql-test/t/show_check.test
Text conflict in mysys/my_delete.c
Text conflict in sql/item.h
Text conflict in sql/item_cmpfunc.h
Text conflict in sql/log.cc
Text conflict in sql/mysqld.cc
Text conflict in sql/repl_failsafe.cc
Text conflict in sql/slave.cc
Text conflict in sql/sql_parse.cc
Text conflict in sql/sql_table.cc
Text conflict in sql/sql_yacc.yy
Text conflict in storage/myisam/ha_myisam.cc

Corrected results for
 stm_auto_increment_bug33029.reject      2009-12-01
		20:01:49.000000000 +0300
       <andrei> @@ -42,9 +42,6 @@
       <andrei>  RETURN i;
       <andrei>  END//
       <andrei>  CALL p1();
       <andrei> -Warnings:
       <andrei> -Note   1592    Statement may not be safe to log in statement
		format.
       <andrei> -Note   1592    Statement may not be safe to log in statement
		format.

There should be indeed no Note present because there is in fact autoincrement 
top-level query in sp() that triggers inserting in yet another auto-inc table.
(todo: alert DaoGang to improve the test).

merging from 5.1 to rep+2 starting at gca(5.1, next-mr) == build@mysql.com-20091104182209-iui387z35159aoyw

------------------------------------------------------------
revno: 3559
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: mysql-pe
timestamp: Fri 2009-08-28 15:23:16 -0300
message:
Break down a large and obnoxious "if" statement. Multiple "if" statements
makes it easy to understand and follow the code (specially in a debugger).

sql/sql_base.cc:
  Break down a large and obnoxious "if" statement. Multiple "if" statements
  makes it easy to understand and follow the code (specially in a debugger).

NOTE: backporting BUG#42150 into next-mr
      Includes latest Andrei's patch (see [2 Feb 18:40] Bugs System)
      and merge.test post-push fix (see [3 Feb 18:04] Bugs System)

The reason of the bug appeared to be overreacting on absense of a
binlog file although the file name had been presented in in the master
binlog index file.
By convention, there should have been only a warning printed and the rest of
`reset master' logics completed.  This did not happen on windows
due to incorrect value of my_errno returned from nt_share_delete().
      
Fixed with correcting my_errno assignment in nt_share_delete() to be ENOENT in 
he event of no binlog file. Some minor refactoring has been made.

No commit message

----------------------------------------------------------------------
ChangeSet@1.2571, 2008-04-08 12:30:06+02:00, vvaintroub@wva. +122 -0
  Bug#32082 : definition of VOID in my_global.h conflicts with Windows
  SDK headers
  
  VOID macro is now removed. Its usage is replaced with void cast.
  In some cases, where cast does not make much sense (pthread_*, printf, 
  hash_delete, my_seek), cast is ommited.


client/mysqladmin.cc:
  Bug#32082 : remove VOID macro
client/mysqldump.c:
  Bug#32082 : remove VOID macro
client/mysqlimport.c:
  Bug#32082 : remove VOID macro
client/mysqlslap.c:
  Bug#32082 : remove VOID macro
client/mysqltest.cc:
  Bug#32082 : remove VOID macro
client/sql_string.cc:
  Bug#32082 : remove VOID macro
extra/comp_err.c:
  Bug#32082 : remove VOID macro
extra/replace.c:
  Bug#32082 : remove VOID macro
include/my_alarm.h:
  Bug#32082 : remove VOID macro
include/my_global.h:
  Bug#32082 : remove VOID macro
libmysql/libmysql.c:
  Bug#32082 : remove VOID macro
mysys/errors.c:
  Bug#32082 : remove VOID macro
mysys/hash.c:
  Bug#32082 : remove VOID macro
mysys/mf_iocache2.c:
  Bug#32082 : remove VOID macro
mysys/mf_loadpath.c:
  Bug#32082 : remove VOID macro
mysys/mf_path.c:
  Bug#32082 : remove VOID macro
mysys/my_append.c:
  Bug#32082 : remove VOID macro
mysys/my_clock.c:
  Bug#32082 : remove VOID macro
mysys/my_copy.c:
  Bug#32082 : remove VOID macro
mysys/my_fstream.c:
  Bug#32082 : remove VOID macro
mysys/my_getwd.c:
  Bug#32082 : remove VOID macro
mysys/my_lib.c:
  Bug#32082 : remove VOID macro
mysys/my_lockmem.c:
  Bug#32082 : remove VOID macro
mysys/my_pthread.c:
  Bug#32082 : remove VOID macro
mysys/my_redel.c:
  Bug#32082 : remove VOID macro
mysys/stacktrace.c:
  Bug#32082 : remove VOID macro
mysys/thr_alarm.c:
  Bug#32082 : remove VOID macro
mysys/thr_lock.c:
  Bug#32082 : remove VOID macro
sql/derror.cc:
  Bug#32082 : remove VOID macro
sql/des_key_file.cc:
  Bug#32082 : remove VOID macro
sql/discover.cc:
  Bug#32082 : remove VOID macro
sql/field.cc:
  Bug#32082 : remove VOID macro
sql/filesort.cc:
  Bug#32082 : remove VOID macro
sql/ha_ndbcluster.cc:
  Bug#32082 : remove VOID macro
sql/ha_partition.cc:
  Bug#32082 : remove VOID macro
sql/handler.cc:
  Bug#32082 : remove VOID macro
sql/hostname.cc:
  Bug#32082 : remove VOID macro
sql/init.cc:
  Bug#32082 : remove VOID macro
sql/item.cc:
  Bug#32082 : remove VOID macro
sql/item_cmpfunc.cc:
  Bug#32082 : remove VOID macro
sql/item_strfunc.cc:
  Bug#32082 : remove VOID macro
sql/lock.cc:
  Bug#32082 : remove VOID macro
sql/log.cc:
  Bug#32082 : remove VOID macro
sql/log_event.cc:
  Bug#32082 : remove VOID macro
sql/mysqld.cc:
  Bug#32082 : remove VOID macro
sql/opt_range.h:
  Bug#32082 : remove VOID macro
sql/protocol.cc:
  Bug#32082 : remove VOID macro
sql/records.cc:
  Bug#32082 : remove VOID macro
sql/sp_head.cc:
  Bug#32082 : remove VOID macro
sql/sp_pcontext.cc:
  Bug#32082 : remove VOID macro
sql/sql_acl.cc:
  Bug#32082 : remove VOID macro
sql/sql_base.cc:
  Bug#32082 : remove VOID macro
sql/sql_cache.cc:
  Bug#32082 : remove VOID macro
sql/sql_connect.cc:
  Bug#32082 : remove VOID macro
sql/sql_db.cc:
  Bug#32082 : remove VOID macro
sql/sql_delete.cc:
  Bug#32082 : remove VOID macro
sql/sql_handler.cc:
  Bug#32082 : remove VOID macro
sql/sql_insert.cc:
  Bug#32082 : remove VOID macro
sql/sql_map.cc:
  Bug#32082 : remove VOID macro
sql/sql_parse.cc:
  Bug#32082 : remove VOID macro
sql/sql_select.cc:
  Bug#32082 : remove VOID macro
sql/sql_servers.cc:
  Bug#32082 : remove VOID macro
sql/sql_show.cc:
  Bug#32082 : remove VOID macro
sql/sql_string.cc:
  Bug#32082 : remove VOID macro
sql/sql_table.cc:
  Bug#32082 : remove VOID macro
sql/sql_test.cc:
  Bug#32082 : remove VOID macro
sql/sql_trigger.cc:
  Bug#32082 : remove VOID macro
sql/sql_update.cc:
  Bug#32082 : remove VOID macro
sql/sql_view.cc:
  Bug#32082 : remove VOID macro
sql/table.cc:
  Bug#32082 : remove VOID macro
sql/tztime.cc:
  Bug#32082 : remove VOID macro
sql/udf_example.c:
  Bug#32082 : remove VOID macro
sql/uniques.cc:
  Bug#32082 : remove VOID macro
sql/unireg.cc:
  Bug#32082 : remove VOID macro
storage/archive/ha_archive.cc:
  Bug#32082 : remove VOID macro
storage/blackhole/ha_blackhole.cc:
  Bug#32082 : remove VOID macro
storage/csv/ha_tina.cc:
  Bug#32082 : remove VOID macro
storage/csv/transparent_file.cc:
  Bug#32082 : remove VOID macro
storage/example/ha_example.cc:
  Bug#32082 : remove VOID macro
storage/federated/ha_federated.cc:
  Bug#32082 : remove VOID macro
storage/heap/hp_clear.c:
  Bug#32082 : remove VOID macro
storage/heap/hp_create.c:
  Bug#32082 : remove VOID macro
storage/heap/hp_test1.c:
  Bug#32082 : remove VOID macro
storage/heap/hp_test2.c:
  Bug#32082 : remove VOID macro
storage/innobase/handler/ha_innodb.cc:
  Bug#32082 : remove VOID macro
storage/myisam/ft_eval.c:
  Bug#32082 : remove VOID macro
storage/myisam/ha_myisam.cc:
  Bug#32082 : remove VOID macro
storage/myisam/mi_changed.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_check.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_close.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_create.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_dbug.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_delete.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_delete_all.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_dynrec.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_info.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_locking.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_log.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_open.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_packrec.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_panic.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_rsame.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_statrec.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_test1.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_test2.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_test3.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_update.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_write.c:
  Bug#32082 : remove VOID macro
storage/myisam/myisamchk.c:
  Bug#32082 : remove VOID macro
storage/myisam/myisamlog.c:
  Bug#32082 : remove VOID macro
storage/myisam/myisampack.c:
  Bug#32082 : remove VOID macro
storage/myisam/sort.c:
  Bug#32082 : remove VOID macro
storage/myisammrg/myrg_close.c:
  Bug#32082 : remove VOID macro
storage/myisammrg/myrg_create.c:
  Bug#32082 : remove VOID macro
storage/myisammrg/myrg_open.c:
  Bug#32082 : remove VOID macro
strings/str_test.c:
  Bug#32082 : remove VOID macro
tests/thread_test.c:
  Bug#32082 : remove VOID macro

-------------------------------------------------------------
revno: 2877
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: 35164-6.0
timestamp: Wed 2008-10-15 19:53:18 -0300
message:
Bug#35164: Large number of invalid pthread_attr_setschedparam calls
Bug#37536: Thread scheduling causes performance degradation at low thread count
Bug#12702: Long queries take 100% of CPU and freeze other applications under Windows

The problem is that although having threads with different priorities
yields marginal improvements [1] in some platforms [2], relying on some
statically defined priorities (QUERY_PRIOR and WAIT_PRIOR) to play well
(or to work at all) with different scheduling practices and disciplines
is, at best, a shot in the dark as the meaning of priority values may
change depending on the scheduling policy set for the process.

Another problem is that increasing priorities can hurt other concurrent
(running on the same hardware) applications (such as AMP) by causing
starvation problems as MySQL threads will successively preempt lower
priority processes. This can be evidenced by Bug#12702.

The solution is to not change the threads priorities and rely on the
system scheduler to perform its job. This also enables a system admin
to increase or decrease the scheduling priority of the MySQL process,
if intended.

Furthermore, the internal wrappers and code for changing the priority
of threads is being removed as they are now unused and ancient.

1. Due to unintentional side effects. On Solaris this could artificially
help benchmarks as calling the priority changing syscall millions of
times is more beneficial than the actual setting of the priority.

2. Where it actually works. It has never worked on Linux as the default
scheduling policy SCHED_OTHER only accepts the static priority 0.


configure.in:
  Remove checks for functions that are not used anymore.
include/config-netware.h:
  Remove unused define.
include/my_pthread.h:
  Remove thread priority changing wrappers.
mysys/my_pthread.c:
  Remove thread priority changing wrappers. They do not work properly
  and their implementations were incorrectly protected by a check for
  HAVE_PTHREAD_SETSCHEDPARAM.
mysys/thr_alarm.c:
  Remove meaningless (100) increase of a thread priority.
sql/mysql_priv.h:
  Remove meaningless thread priority values.
sql/mysqld.cc:
  Don't change thread priorities.
sql/slave.cc:
  Don't change thread priorities.
sql/slave.h:
  Update function prototype.
sql/sql_parse.cc:
  Don't change thread priorities.
sql/sql_prepare.cc:
  Don't change thread priorities.
sql/unireg.h:
  Mark flag as obsolete.
storage/innobase/handler/ha_innodb.cc:
  Remove use of obsolete flag and associated behavior.
storage/innobase/include/srv0srv.h:
  Remove use of obsolete flag and associated variables.
storage/innobase/os/os0thread.c:
  Remove use of obsolete flag and associated behavior.
storage/innobase/srv/srv0srv.c:
  Remove use of obsolete flag and associated variables.

------------------------------------------------------------
revno: 2630.13.2
committer: Davi Arnaut <davi@sun.com>
branch nick: WL4284-6.0
timestamp: Thu 2008-07-03 18:26:51 -0300
message:
Remove unused USING_TRANSACTIONS macro which unnecessarily
cumbers the code. This macro is a historical leftover and
has no practical use since its unconditionally defined.


sql/handler.cc:
  Remove an always defined #ifdef (USING_TRNASACTIONS).
sql/handler.h:
  Remove an always defined #ifdef (USING_TRNASACTIONS).
sql/log.cc:
  Remove an always defined #ifdef (USING_TRNASACTIONS).
sql/log_event.cc:
  Remove an always defined #ifdef (USING_TRNASACTIONS).
sql/set_var.cc:
  Remove an always defined #ifdef (USING_TRNASACTIONS).
sql/sql_class.cc:
  Remove an always defined #ifdef (USING_TRNASACTIONS).
sql/sql_class.h:
  Remove an always defined #ifdef (USING_TRNASACTIONS).
sql/sql_parse.cc:
  Remove an always defined #ifdef (USING_TRNASACTIONS).

------------------------------------------------------------
revno: 2642
committer: davi@mysql.com/endora.local
timestamp: Fri 2008-05-16 01:29:09 -0300
message:
Fix for a valgrind warning due to a jump on a uninitialized
variable. The problem was that the sql profile preparation
function wasn't being called for all possible code paths
of query execution. The solution is to move the preparation
to the dispatch_command function and to explicitly call the
profile preparation function on bootstrap.

beyond unsigned long.
BUG#44779: binlog.binlog_max_extension may be causing failure on 
next test in PB
            
NOTE1: this is the backport to next-mr.
NOTE2: already includes patch for BUG#44779.
            
Binlog file extensions would turn into negative numbers once the
variable used to hold the value reached maximum for signed
long. Consequently, incrementing value to the next (negative) number
would lead to .000000 extension, causing the server to fail.
                        
This patch addresses this issue by not allowing negative extensions
and by returning an error on find_uniq_filename, when the limit is
reached. Additionally, warnings are printed to the error log when the
limit is approaching. FLUSH LOGS will also report warnings to the
user, if the extension number has reached the limit. The limit has been
set to 0x7FFFFFFF as the maximum.

mysql-test/suite/binlog/t/binlog_max_extension.test:
  Test case added that checks the maximum available number for
  binlog extensions.
sql/log.cc:
  Changes to find_uniq_filename and test_if_number.
sql/log.h:
  Added macros with values for MAX_LOG_UNIQUE_FN_EXT and
  LOG_WARN_UNIQUE_FN_EXT_LEFT, as suggested in review.

------------------------------------------------------------
revno: 2627
committer: davi@mysql.com/endora.local
timestamp: Wed 2008-04-23 13:25:02 -0300
message:
Fix for a build failure on Windows due to ssize_t
not being declared.

Original changeset:
------------------------------------------------------------
revno: 2626
committer: davi@mysql.com/endora.local
timestamp: Wed 2008-04-23 09:33:25 -0300
message:
Fix for main.ssl and main.ssl_compress test case failures under pool-of-threads.

The problem is that the SSL layer has a read buffer and might read
more data than requested by the VIO layer. The SSL layer empties the
socket buffer which causes the socket to not be signaled for IO if
the client is waiting for a command which is sitting in the read
buffer.

The solution is to retrieve from the transport layer the number of
bytes waiting in the read buffer. The data in the read buffer needs
to be processed before waiting for more data.

 inside a stored routine" from 6.0-codebase.

------------------------------------------------------------
revno: 2597.42.4
committer: davi@mysql.com/endora.local
timestamp: Tue 2008-04-15 17:29:42 -0300
message:
Bug#36004 mysql_stmt_prepare resets the list of warnings

Although the manual says that "the list of messages is reset
for each new statement that uses a table", the list of messages
is being unconditionally reset for prepare commands.

The solution is to enforce that the prepare command will only
reset the message list if the statement being prepared uses
a table or a warning is pushed.


tests/mysql_client_test.c:
  Add test case for Bug#36004

mysql-test/t/sp-error.test:
  Backport test of Bug#36510 (the bug itself is fixed by other
  backports, inc. SINGAL code).

------------------------------------------------------------
revno: 2572.23.1
committer: davi@mysql.com/endora.local
timestamp: Wed 2008-03-19 09:03:08 -0300
message:
Bug#17954 Threads_connected > Threads_created

The problem is that insert delayed threads are counted as connected
but not as created, leading to a Threads_connected value greater then
the Threads_created value.

The solution is to enforce the documented behavior that the
Threads_connected value shall be the number of currently
open connections and that Threads_created shall be the
number of threads created to handle connections.


mysql-test/r/status.result:
  Add test case result for Bug#17954
mysql-test/t/status.test:
  Add test case for Bug#17954
sql/mysqld.cc:
  Change Threads_connected to reflect the number of
  open connections. SHOW_INT type variables are not
  reset.

------------------------------------------------------------
revno: 2476.1116.1
committer: davi@mysql.com/endora.local
timestamp: Fri 2007-12-14 10:10:19 -0200
message:
DROP TABLE under LOCK TABLES simultaneous to a FLUSH TABLES
WITH READ LOCK (global read lock) can lead to a deadlock.

The solution is to not wait for the global read lock if the
thread is holding any locked tables.

Related to bugs 23713 and 32395. This issues is being fixed
only on 6.0 because it depends on the fix for bug 25858 --
which was fixed only on 6.0.

------------------------------------------------------------
revno: 2476.784.3
committer: davi@moksha.local
timestamp: Tue 2007-10-02 21:27:31 -0300
message:
Bug#25858 Some DROP TABLE under LOCK TABLES can cause deadlocks
        
When a client (connection) holds a lock on a table and attempts to
drop (obtain a exclusive lock) on a second table that is already
held by a second client and the second client then attempts to
drop the table that is held by the first client, leads to a
circular wait deadlock. This scenario is very similar to trying to
drop (or rename) a table while holding read locks and are
correctly forbidden.
        
The solution is to allow a drop table operation to continue only
if the table being dropped is write (exclusively) locked, or if
the table is temporary, or if the client is not holding any
locks. Using this scheme prevents the creation of a circular
chain in which each client is waiting for one table that the
next client in the chain is holding.
            
This is incompatible change, as can be seen by number of tests
cases that needed to be fixed, but is consistent with respect to
behavior of the different scenarios in which the circular wait
might happen.

mysql-test/r/drop.result:
  Test case result for Bug#25858
mysql-test/r/group_by.result:
  Fix test case result wrt drop table under lock tables -- unlock tables
  before dropping table.
mysql-test/r/insert_notembedded.result:
  Fix test case result wrt drop table under lock tables -- unlock tables
  before dropping table
mysql-test/r/lock.result:
  Fix test case result wrt drop table under lock tables -- unlock tables
  before dropping table.
mysql-test/r/lock_multi.result:
  Fix test case result wrt drop table under lock tables -- unlock tables
  before dropping table.
mysql-test/r/myisam.result:
  Fix test case result wrt drop table under lock tables -- unlock tables
  before dropping table.
mysql-test/r/view.result:
  Fix test case result wrt drop table under lock tables -- unlock tables
  before dropping table.
mysql-test/t/drop.test:
  Add test case for Bug#25858
mysql-test/t/group_by.test:
  Fix test case: unlock tables in preparation for a drop table. In some
  circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/insert_notembedded.test:
  Fix test case: unlock tables in preparation for a drop table. In some
  circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/lock.test:
  Fix test case: unlock tables in preparation for a drop table. In some
  circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/lock_multi.test:
  Fix test case: unlock tables in preparation for a drop table. In some
  circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/myisam.test:
  Fix test case: unlock tables in preparation for a drop table. In some
  circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/query_cache_notembedded.test:
  Fix test case: unlock tables in preparation for a drop table. In some
  circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/view.test:
  Fix test case: unlock tables in preparation for a drop table. In some
  circumstances, dropping tables while holding locks leads to a deadlock.
sql/lock.cc:
  When trying to obtain a name lock under lock tables, ensure that the table is properly exclusively locked and fail otherwise.

revno: 2476.784.2
committer: davi@moksha.local
timestamp: Thu 2007-09-27 16:56:27 -0300 
message:
Bug#28870 check that table locks are released/reset
    
The problem is that some mysql_lock_tables error paths are not
resetting the tables lock type back to TL_UNLOCK. If the lock
types are not reset properly, a table might be returned to the
table cache with wrong lock_type.
      
The proposed fix is to ensure that the tables lock type is always
properly reset when mysql_lock_tables fails. This is a
incompatible change with respect to the process state information.


sql/lock.cc:
  Merge mysql_lock_tables cleanup sequence and the reset_lock_data
  function into a single function and take steps to ensure it is
  always called for each error exit path. Also remove references
  to the redundant THD::locked variable which was almost exclusively
  used by this function and the same information is already on proc_info.
sql/sql_class.cc:
  Remove references to the THD::locked variable.
sql/sql_class.h:
  Remove the THD::locked variable.
sql/sql_show.cc:
  Remove references to THD:locked, state_info will now default to proc_info.

The mentioned on the bug report set of bugs fixes have not be pushed to the main trees.

Fixed with extracting commits done to 6.0-rpl tree and applying them to the main 5.1.
Notes.
1. part of changes - the mtr's specific - were packported to the main 5.0 tree for mtr v1
   as http://lists.mysql.com/commits/46562
   However, there is no that fix anymore in the mtr v2. (This fact was mailed to mtr maintaining
   people).

2. Bug@36929  crash in kill_zombie_dump_threads-> THD::awake() with replication tests
   is not backported because the base code of the patch is libevent and that was removed
   from the main trees due to its instability.

client/mysqlbinlog.cc:
  fixes for BUG#35546
mysql-test/suite/rpl/r/rpl_bug41902.result:
  the new tests result file is added.
mysql-test/suite/rpl/t/rpl_bug41902-slave.opt:
  conf file for bug41902 testing is added.
mysql-test/suite/rpl/t/rpl_bug41902.test:
  regression tests for Bug #41902 is added.
sql/log.cc:
  collection of changes due to Bug #48463.
sql/log.h:
  collection of changes due to Bug #48463.
sql/rpl_rli.h:
  collection of changes due to Bug #48463.
sql/slave.cc:
  collection of changes due to Bug #48463.
sql/sql_repl.cc:
  collection of changes due to Bug #48463.

Backport from 6.0.14 to 5.6.0

Original code from Guilhem Bichot

Backport from 6.0.14 to 5.6.0

Original code from Sergei Golubchik

Backport from 6.0.14 to 5.6.0

Original code from Sergei Golubchik

Post-push fix: Removed MTRv1 arguments according to the
original patch. Although there is a version check, the patch
was pushed to a 5.1 GA staging tree, while the version check 
considers version 5.2. This makes the deprecated parameters 
to be used, despite the fact that they are not valid anymore.

Part of MTRv1 is currently used in RQG semisync test, and this
was causing the test to fail on slave startup.

It should be safe to uncomment when merging up to celosia.