GitLab

fails in PB sporadically)
      
The IO thread can concurrently access the relay log IO_CACHE
while another thread is performing an FLUSH LOGS procedure.
      
FLUSH LOGS closes and reopens the relay log and while doing so it
(re)initializes its IO_CACHE. During this procedure the IO_CACHE
mutex is also reinitialized, which can cause problems if some
other thread (namely the IO THREAD) is concurrently accessing it
at the time .
      
This patch fixes the problem by extending the interface of the
flush_master_info function to also include a second paramater, 
"need_relay_log_lock", stating whether the thread should grab the 
relay log lock or not before actually flushing the relay log. 
Also, IO thread now calls flush_master_info with this flag set 
when it flushes master info with in the event read_event loop.

Finally, we also increase loop time in rpl_heartbeat_basic test 
case, so that the number of calls to flush logs doubles, stressing
this part of the code a little more.

mysql-test/suite/rpl/t/rpl_heartbeat_basic.test:
  Doubled the number of iterations on the FLUSH LOGS loop by
  doubling the time available to perform all iterations.
sql/repl_failsafe.cc:
  Updating flush_master_info call so that it uses two parameters
  instead of one.
sql/rpl_mi.cc:
  Updating flush_master_info call so that it uses two parameters
  instead of one.
sql/rpl_mi.h:
  Changed flush_master_info interface. Now takes a second parameter
  instead of just one. The second parameter is: need_lock_relay_log.
sql/rpl_rli.cc:
  Small fix in comment.
sql/slave.cc:
  Updating flush_master_info call so that it uses two parameters
  instead of one.
sql/sql_repl.cc:
  Updating flush_master_info call so that it uses two parameters
  instead of one.

Until-pos guarding did not distiguish the master originated events from ones that the slave 
can introduce to the relay log e.g Rotate to the next relay log at slave restarting.
The local Rotate's coordinate are incomparable with the Until-master-pos.
That led to the unexpectable stop this bug describes.

Fixed with to avoid Until-master-pos comparison for a local slave's event.
Notice that if --replicate-same-server is true such event is treated as coming from
the master side.


mysql-test/r/rpl_until.result:
  results changed.
mysql-test/t/rpl_until.test:
  regression test for bug#47210 is added.
sql/slave.cc:
  st_relay_log_info::is_until_satisfied() is augmented with avoidance of 
  Until-master-pos comparison for a local slave's event.
  if --replicate-same-server is true such event is treated as coming from
  the master side.
sql/slave.h:
  signature of is_until_satisfied() changed to supply THD and Event to the routine.

  function/ syntax
  glob(7) wildcards
  unit tests

2630.39.1, 2630.28.29, 2630.34.3, 2630.34.2, 2630.34.1, 2630.29.29,
2630.29.28, 2630.31.1, 2630.28.13, 2630.28.10, 2617.23.14 and
some other minor revisions.

This patch implements: 

WL#4264 "Backup: Stabilize Service Interface" -- all the
server prerequisites except si_objects.{h,cc} themselves (they can
be just copied over, when needed).

WL#4435: Support OUT-parameters in prepared statements.

(and all issues in the initial patches for these two
tasks, that were discovered in pushbuild and during testing).

Bug#39519: mysql_stmt_close() should flush all data
associated with the statement.

After execution of a prepared statement, send OUT parameters of the invoked
stored procedure, if any, to the client.

When using the binary protocol, send the parameters in an additional result
set over the wire.  When using the text protocol, assign out parameters to
the user variables from the CALL(@var1, @var2, ...) specification.

The following refactoring has been made:
  - Protocol::send_fields() was renamed to Protocol::send_result_set_metadata();
  - A new Protocol::send_result_set_row() was introduced to incapsulate
    common functionality for sending row data.
  - Signature of Protocol::prepare_for_send() was changed: this operation
    does not need a list of items, the number of items is fully sufficient.

The following backward incompatible changes have been made:
  - CLIENT_MULTI_RESULTS is now enabled by default in the client;
  - CLIENT_PS_MULTI_RESUTLS is now enabled by default in the client.

include/mysql.h:
  Add a new flag to MYSQL_METHODS::flush_use_result
  function pointer. This flag determines if all results
  should be flushed or only the first one:
      
  - if flush_all_results is TRUE, then cli_flush_use_result()
    will read/flush all pending results. I.e. it will read
    all packets while server status attribute indicates that
    there are more results. This is a new semantic, required
    to fix the bug.
              
  - if flush_all_results is FALSE, the old sematic
    is preserved -- i.e. cli_flush_use_result() reads data
    until first EOF-packet.
include/mysql.h.pp:
  Update the ABI with new calls (compatible changes).
include/mysql_com.h:
  Add CLIENT_PS_OUT_PARAMS -- a client capability indicating that the client supportsю
libmysql/libmysql.c:
  Add mysql_stmt_next_result() -- analogue of mysql_next_result() for binary protocol.
  Fix a minor bug in alloc_fields() -- not all members were copied over,
  and some only shallow-copied (catalog).
  Flush all results in mysql_stmt_close() (Bug#39519).
libmysqld/lib_sql.cc:
  Rename send_fields() -> send_result_set_metadata().
  Refactoring: change prepare_for_send() so that it accepts only 
  what it really needs -- a number of elements in the list.
mysql-test/r/ps.result:
  Update results: WL#4435.
mysql-test/t/ps.test:
  WL#4435: A test case for an SQL-part of the problem.
sql-common/client.c:
  Bug#39519.
  Implement new functionality in cli_flush_use_result():
  if flush_all_delete is TRUE, then it should read/flush
  all pending results.
sql/Makefile.am:
  Add a new header sql_prepare.h to the list
  of build headers.
sql/events.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/handler.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/mysql_priv.h:
  Move sql_prepare.cc-specific declarations to a new
  header - sql_prepare.h.
sql/procedure.h:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/protocol.cc:
  Move the logic responsible for sending of one result
  set row to the Protocol class. Define a template
  for end-of-statement action. 
  Refactoring: change prepare_for_send() so that it accepts 
  only what it really needs -- a number of elements in the list.
  Rename send_fields() to send_result_set_metadata().
sql/protocol.h:
  Update with new declarations (WL#4435).
  Rename send_fields() -> send_result_set_metadata().
  prepare_for_send() only needs the number of columns to send,
  and doesn't use the item list - update signature to require
  only what's needed.
  Add a new protocol type -- Protocol_local.
sql/repl_failsafe.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/slave.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_acl.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_base.cc:
  Include sql_prepare.h (for Reprepare_observer).
sql/sql_cache.cc:
  Extend the query cache flags block to be able
  to store a numeric id for the result format,
  not just a flag binary/non-binary.
sql/sql_class.cc:
  Update to use the rename of Protocol::send_fields()
  to Protocol::send_result_set_metadata().
  Use Protocol::send_one_result_set_row().
sql/sql_class.h:
  Move the declaration of Reprepare_observer to the 
  new header - sql_prepare.h.
  Update to the new signature of class Protocol::send_fields().
sql/sql_connect.cc:
  Use a protocol template method instead of
  raw NET layer API at the end of a statement.
sql/sql_cursor.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_error.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_handler.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
  Use new method Protocol::send_one_result_set_row().
sql/sql_help.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_lex.cc:
  Initialize multi_statements variable.
  Add a handy constant for empty lex
  string.
sql/sql_lex.h:
  Add a separate member for a standalone
  parsing option - multi-statements support.
sql/sql_list.cc:
  sql_list.h is a standalone header now, 
  no need to include mysql_priv.h.
sql/sql_list.h:
  Make sql_list.h a stand-alone header.
sql/sql_parse.cc:
  Include sql_prepare.h for prepared
  statements- related declarations.
  Use a new Protocol template method to end
  each statement (send OK, EOF or ERROR to
  the client).
sql/sql_prepare.cc:
  Implement Execute Direct API (WL#4264), 
  currently unused. It will be used by the service
  interface (Backup).
  Use a new header - sql_prepare.h.
  Add support for OUT parameters in the 
  binary and text protocol (prepared statements 
  only).
sql/sql_prepare.h:
  Add a new header to contain (for now)
  all prepared statement- external
  related declarations.
sql/sql_profile.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_repl.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_select.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_show.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_string.h:
  Add a way to convert a String to LEX_STRING.
sql/sql_table.cc:
  Rename: Protocol::send_fields() -> 
  Protocol::send_result_set_metadata().
sql/sql_update.cc:
  Remove an extraneous my_error(). The error
  is already reported in update_non_unique_table_error().
sql/sql_yacc.yy:
  Support for multi-statements is an independent
  property of parsing, not derived from 
  the protocol type.
tests/mysql_client_test.c:
  Add tests for WL#4435 (binary protocol).

      
Implemented the server infrastructure for the fix:

1. Added a function LEX_STRING *thd_query_string(THD) to return
a LEX_STRING structure instead of char *.
This is the function that must be called in innodb instead of 
thd_query()

2. Did some encapsulation in THD : aggregated thd_query and 
thd_query_length into a LEX_STRING and made accessor and mutator 
methods for easy code updating. 

3. Updated the server code to use the new methods where applicable.

      
The BINLOG statement was sharing too much code with the slave SQL thread, introduced with
the patch for Bug#32407. This caused statements to be logged with the wrong server_id, the
id stored inside the events of the BINLOG statement rather than the id of the running 
server.
      
Fix by rearranging code a bit so that only relevant parts of the code are executed by
the BINLOG statement, and the server_id of the server executing the statements will 
not be overrided by the server_id stored in the 'format description BINLOG statement'.

mysql-test/extra/binlog_tests/binlog.test:
  Added test to verify if the server_id stored in the 'format 
  description BINLOG statement' will override the server_id
  of the server executing the statements.
mysql-test/suite/binlog/r/binlog_row_binlog.result:
  Test result for bug#46640
mysql-test/suite/binlog/r/binlog_stm_binlog.result:
  Test result for bug#46640
sql/log_event.cc:
  Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in any case
  makes more sense, and is needed as update_pos() is no longer called when executing
  BINLOG statements.
  
  Moved setting of rli->relay_log.description_event_for_exec from 
  Format_description_log_event::do_update_pos() to 
  Format_description_log_event::do_apply_event()
sql/log_event_old.cc:
  Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in any case
  makes more sense, and is needed as update_pos() is no longer called when executing
  BINLOG statements.
sql/slave.cc:
  The skip flag is no longer needed, as the code path for BINLOG statement has been 
  cleaned up.
sql/sql_binlog.cc:
  Don't invoke the update_pos() code path for the BINLOG statement, as it contains code 
  that is redundant and/or harmful (especially setting thd->server_id).

mysql-test/suite/rpl/r/rpl_stop_middle_group.result:
  the new result file
mysql-test/suite/rpl/t/rpl_stop_middle_group.test:
  renamed from rpl_row_stop_middle_update and added a regression test for bug#45940.

There are three internal status for slave I/O thread, both
MYSQL_SLAVE_RUN_NOT_CONNECT and MYSQL_SLAVE_NOT_RUN are reported
as 'No' for Slave_IO_running of command SHOW SLAVE STATUS.

Change MYSQL_SLAVE_RUN_NOT_CONNECT to be reported as 'Connecting'.

NOTE: Backporting the patch to next-mr.
      
The slave was crashing while failing to execute the init_slave() function.
      
The issue stems from two different reasons:
      
1 - A failure while allocating the master info structure generated a
    segfault due to a NULL pointer.
      
2 - A failure while recovering generated a segfault due to a non-initialized
    relay log file. In other words, the mi->init and rli->init were both set to true
    before executing the recovery process thus creating an inconsistent state as the
    relay log file was not initialized.
      
To circumvent such problems, we refactored the recovery process which is now executed
while initializing the relay log. It is ensured that the master info structure is
created before accessing it and any error is propagated thus avoiding to set mi->init
and rli->init to true when for instance the relay log is not initialized or the relay
info is not flushed.
      
The changes related to the refactory are described below:
      
1 - Removed call to init_recovery from init_slave.
      
2 - Changed the signature of the function init_recovery.
      
3 - Removed flushes. They are called while initializing the relay log and master
    info.
      
4 - Made sure that if the relay info is not flushed the mi-init and rli-init are not
    set to true.
      
In this patch, we also replaced the exit(1) in the fault injection by DBUG_ABORT()
to make it compliant with the code guidelines.

On Mac OS X or Windows, sending a SIGHUP to the server or a
asynchronous flush (triggered by flush_time), would cause the
server to crash.

The problem was that a hook used to detach client API handles
wasn't prepared to handle cases where the thread does not have
a associated session.

The solution is to verify whether the thread has a associated
session before trying to detach a handle.

mysql-test/r/federated_debug.result:
  Add test case result for Bug#47525
mysql-test/t/federated_debug-master.opt:
  Debug point.
mysql-test/t/federated_debug.test:
  Add test case for Bug#47525
sql/slave.cc:
  Check whether a the thread has a associated session.
sql/sql_parse.cc:
  Add debug code to simulate a reload without thread session.

NOTE: Backporting the patch to next-mr.
      
The fix proposed in BUG#35542 and BUG#31665 introduces a performance issue
when fsyncing the master.info, relay.info and relay-log.bin* after #th events.
Although such solution has been proposed to reduce the probability of corrupted
files due to a slave-crash, the performance penalty introduced by it has
made the approach impractical for highly intensive workloads.
      
In a nutshell, the option --syn-relay-log proposed in BUG#35542 and BUG#31665
simultaneously fsyncs master.info, relay-log.info and relay-log.bin* and
this is the main source of performance issues.
      
This patch introduces new options that give more control to the user on
what should be fsynced and how often:
      
   1) (--sync-master-info, integer) which syncs the master.info after #th event;
   2) (--sync-relay-log, integer) which syncs the relay-log.bin* after #th
   events.
   3) (--sync-relay-log-info, integer) which syncs the relay.info after #th
   transactions.
      
   To provide both performance and increased reliability, we recommend the following
   setup:
      
   1) --sync-master-info = 0 eventually the operating system will fsync it;
   2) --sync-relay-log = 0 eventually the operating system will fsync it;
   3) --sync-relay-log-info = 1 fsyncs it after every transaction;
      
Notice, that the previous setup does not reduce the probability of
corrupted master.info and relay-log.bin*. To overcome the issue, this patch also
introduces a recovery mechanism that right after restart throws away relay-log.bin*
retrieved from a master and updates the master.info based on the relay.info:
      
      
   4) (--relay-log-recovery, boolean) which enables a recovery mechanism that
   throws away relay-log.bin* after a crash.
      
However, it can only recover the incorrect binlog file and position in master.info,
if other informations (host, port password, etc) are corrupted or incorrect,
then this recovery mechanism will fail to work.

Improving an error report generating.

backporting from 6.0 code base to 5.1.

Backporting BUG#44058 BUG#42244 BUG#45672 BUG#45673
Backporting BUG#45819 BUG#45973 BUG#39012

with gcc 4.3.2

Cleaning up warnings not present in 5.0.

when compiled with Sun Studio compiler).

The thing is that Sun Studio compiler calls destructor of stack
objects when pthread_exit() is called. That triggered an assertion
in DBUG_ENTER()/DBUG_RETURN() validation logic (if DBUG_ENTER() is
used in the beginning of function, all returns should be replaced
by DBUG_RETURN/DBUG_VOID_RETURN macros).

A fix is to explicitly use DBUG_LEAVE macro.

           But there is no Last_IO_Error reported.

On the master, if a binary log event is larger than max_allowed_packet,
ER_MASTER_FATAL_ERROR_READING_BINLOG and the specific reason of this error is
sent to a slave when it requests a dump from the master, thus leading
the I/O thread to stop.

On a slave, the I/O thread stops when receiving a packet larger than max_allowed_packet.

In both cases, however, there was no Last_IO_Error reported.

This patch adds code to report the Last_IO_Error and exact reason before stopping the
I/O thread and also reports the case the out memory pops up while
handling packets from the master.


sql/sql_repl.cc:
  The master send the Specific reasons instead of "error reading log entry" to the slave which is requesting a dump.
  if an fatal error is returned by read_log_event function.

WL#2265 (RESIGNAL)

Manual merge of SIGNAL and RESIGNAL to mysql-trunk-signal,
plus required dependencies.

If the SQL Thread fails to execute an event due to a temporary error (e.g.
ER_LOCK_DEADLOCK) and the option "--slave_transaction_retries" is set the SQL
Thread should not be aborted and the transaction should be restarted from the
beginning and re-executed.

Unfortunately, a wrong interpretation of the THD::is_fatal_error was preventing
this behavior. In a nutshell, "this variable is set to TRUE if an execution of a
compound statement cannot continue. In particular, it is used to disable access
to the CONTINUE or EXIT handlers of stored routines. So even temporary errors
may have this variable set.

To fix the bug, we have done what follows:

   DBUG_ENTER("has_temporary_error");

-  if (thd->is_fatal_error)
-    DBUG_RETURN(0);
-
   DBUG_EXECUTE_IF("all_errors_are_temporary_errors",
                   if (thd->main_da.is_error())
                   {

Bug#45243: crash on win in sql thread clear_tables_to_lock() -> free()
Bug#45242: crash on win in mysql_close() -> free()
Bug#45238: rpl_slave_skip, rpl_change_master failed (lost connection) for STOP SLAVE
Bug#46030: rpl_truncate_3innodb causes server crash on windows
Bug#46014: rpl_stm_reset_slave crashes the server sporadically in pb2

When killing a user session on the server, it's necessary to
interrupt (notify) the thread associated with the session that
the connection is being killed so that the thread is woken up
if waiting for I/O. On a few platforms (Mac, Windows and HP-UX)
where the SIGNAL_WITH_VIO_CLOSE flag is defined, this interruption
procedure is to asynchronously close the underlying socket of
the connection.

In order to enable this schema, each connection serving thread
registers its VIO (I/O interface) so that other threads can
access it and close the connection. But only the owner thread of
the VIO might delete it as to guarantee that o...

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


sql/ha_myisam.cc:
  Bug #38816: kill + flush tables with read lock + stored
              procedures causes crashes!
  
  Modification of THD::query/query_length has been guarded
  with the a THD::set_query() method call/LOCK_thd_data
  mutex.
  Unnecessary locking with the global LOCK_thread_count
  mutex has been removed.
sql/log_event.cc:
  Bug #38816: kill + flush tables with read lock + stored
              procedures causes crashes!
  
  Modification of THD::query/query_length has been guarded
  with the THD::set_query()) method call/LOCK_thd_data
  mutex.
sql/slave.cc:
  Bug #38816: kill + flush tables with read lock + stored
              procedures causes crashes!
  
  Modification of THD::query/query_length has been guarded
  with the THD::set_query() method call/LOCK_thd_data mutex.
  
  The THD::LOCK_delete mutex has been renamed to
  THD::LOCK_thd_data.
sql/sp_head.cc:
  Bug #38816: kill + flush tables with read lock + stored
              procedures causes crashes!
  
  Modification of THD::query/query_length has been guarded
  with the a THD::set_query() method call/LOCK_thd_data
  mutex.
sql/sql_class.cc:
  Bug #38816: kill + flush tables with read lock + stored
              procedures causes crashes!
  
  The new THD::LOCK_thd_data mutex and THD::set_query()
  method has been added to guard modifications of THD::query/
  THD::query_length fields, also the Statement::set_statement()
  method has been overloaded in the THD class.
  
  The THD::LOCK_delete mutex has been renamed to
  THD::LOCK_thd_data.
sql/sql_class.h:
  Bug #38816: kill + flush tables with read lock + stored
              procedures causes crashes!
  
  The new THD::LOCK_thd_data mutex and THD::set_query()
  method has been added to guard modifications of THD::query/
  THD::query_length fields, also the Statement::set_statement()
  method has been overloaded in the THD class.
  
  The THD::LOCK_delete mutex has been renamed to
  THD::LOCK_thd_data.
sql/sql_insert.cc:
  Bug #38816: kill + flush tables with read lock + stored
              procedures causes crashes!
  
  Modification of THD::query/query_length has been guarded
  with the a THD::set_query() method call/LOCK_thd_data
  mutex.
sql/sql_parse.cc:
  Bug #38816: kill + flush tables with read lock + stored
              procedures causes crashes!
  
  Modification of THD::query/query_length has been guarded
  with the a THD::set_query() method call/LOCK_thd_data mutex.
sql/sql_repl.cc:
  Bug #38816: kill + flush tables with read lock + stored
              procedures causes crashes!
  
  The THD::LOCK_delete mutex has been renamed to
  THD::LOCK_thd_data.
sql/sql_show.cc:
  Bug #38816: kill + flush tables with read lock + stored
              procedures causes crashes!
  
  Inter-thread read of THD::query/query_length field has
  been protected with a new per-thread LOCK_thd_data
  mutex in the mysqld_list_processes function.

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

        
The "get_master_version_and_clock(...)" function in sql/slave.cc ignores 
error and passes directly when queries fail, or queries succeed 
but the result retrieved is empty.
  
The "get_master_version_and_clock(...)" function should try to reconnect master
if queries fail because of transient network problems, and fail otherwise.
The I/O thread should print a warning if the some system variables do not 
exist on master (very old master)

mysql-test/extra/rpl_tests/rpl_get_master_version_and_clock.test:
  Added test file for bug #45214
mysql-test/suite/rpl/r/rpl_get_master_version_and_clock.result:
  Added test result for bug #45214
mysql-test/suite/rpl/t/rpl_get_master_version_and_clock.test:
  Added test file for bug #45214
sql/slave.cc:
  The 'is_network_error()' function is added for checking if the error is caused by network.
  Added a new return value (2) to 'get_master_version_and_clock()' function result set 
  to indicate transient network errors when queries fail, and the caller should 
  try to reconnect in this case.

timeout
            
In STMT and MIXED modes, a statement that changes both non-transactional and
transactional tables must be written to the binary log whenever there are
changes to non-transactional tables. This means that the statement gets into the
binary log even when the changes to the transactional tables fail. In particular
, in the presence of a failure such statement is annotated with the error number
and wrapped in a begin/rollback. On the slave, while applying the statement, it
is expected the same failure and the rollback prevents the transactional changes
to be persisted.
            
Unfortunately, statements that fail due to concurrency issues (e.g. deadlocks,
timeouts) are logged in the same way causing the slave to stop as the statements
are applied sequentially by the SQL Thread. To fix this bug, we automatically
ignore concurrency failures on the slave. Specifically, the following failures
are ignored: ER_LOCK_WAIT_TIMEOUT, ER_LOCK_DEADLOCK and ER_XA_RBDEADLOCK.

            
The reason for the crash was rotate_relay_log (mi=0x0) did not verify
the passed value of active_mi.  There are more cases where active_mi
is supposed to be non-zero e.g change_master(), stop_slave(), and it's
reasonable to protect from a similar crash all of them with common
fixes.
            
Fixed with spliting end_slave() in slave threads release and slave
data clean-up parts (a new close_active_mi()). The new function is
invoked at the very end of close_connections() so that all users of
active_mi are proven to have left.

sql/mysqld.cc:
  added the 2nd part (data) of the slave's clean up.
sql/slave.cc:
  end_slave() is split in two part to release the slave threads and the remained
  resources separately.
  The new close_active_mi() should be called after all possible users ofactive_mi
  has left, i.e at the very end of close_connections().
sql/slave.h:
  interface to the new end_active_mi() function is added.

This is a backport of BUG#43076.

with gcc 4.3.2
      
Compiling MySQL with gcc 4.3.2 and later produces a number of 
warnings, many of which are new with the recent compiler
versions.
      
This bug will be resolved in more than one patch to limit the
size of changesets. This is the first patch, fixing a number 
of the warnings, predominantly "suggest using parentheses 
around && in ||", and empty for and while bodies.

with gcc 4.3.2

Compiling MySQL with gcc 4.3.2 and later produces a number of 
warnings, many of which are new with the recent compiler
versions.

This bug will be resolved in more than one patch to limit the
size of changesets. This is the first patch, fixing a number 
of the warnings, predominantly "suggest using parentheses 
around && in ||", and empty for and while bodies.

The server was not cleaning the last IO error and error number when
resetting slave.

This patch addresses this issue by backporting into 5.1 part of the
patch in BUG 34654. A fix for this issue had already been pushed into
6.0 as part of the aforementioned bug, however the patch also included
some refactoring. The fix for 5.1 does not take into account the
refactoring part.

mysql-test/extra/rpl_tests/rpl_reset_slave.test:
  Backported the test case and improved with deploying include/start_slave.inc
  in relevant spots.
sql/slave.cc:
  Backported part of patch from 6.0 that includes cleaning 
  mi->clear_error() at:
    1. beginning of handle_slave_io
    2. on successful connection
  
  Also, backported the assertion added in the original patch.
sql/sql_repl.cc:
  Backported the call to mi->clear_error() on reset_slave().

stop/start slave
      
When stopping and restarting the slave while it is replicating
temporary tables, the server would crash or raise an assertion
failure. This was due to the fact that although temporary tables are
saved between slave threads restart, the reference to the thread in
use (table->in_use) was not being properly updated when the restart
happened (it would still reference the old/invalid thread instead of
the new one).
      
This patch addresses this issue by resetting the reference to the new
slave thread on slave thread restart.

mysql-test/r/rpl_temporary.result:
  Result file.
mysql-test/t/rpl_temporary.test:
  Test case that checks that both failures go away.
sql/slave.cc:
  Changed slave.cc to reset sql_thd reference in temporary tables.

The issue of the current bug is unguarded access to mi->slave_running 
by the shutdown thread calling end_slave() that is bug#29968 
(alas happened not to be cross-linked with the current bug)

Fixed:

with removing the unguarded read of the running status
and perform reading it in terminate_slave_thread()
at time run_lock is taken (mostly bug#29968 backporting, still with some
improvements over that patch - see the error reporting from 
terminate_slave_thread()).
Issue of bug#38716 is fixed here for 5.0 branch as well.

Note:

There has been a separate artifact identified - 
a race condition between init_slave() and  end_slave() - 
reported as  Bug#44467.

mysql-test/r/rpl_bug38694.result:
  a new results file is added.
mysql-test/t/rpl_bug38694-slave.opt:
  simulating delay at slave threads shutdown.
mysql-test/t/rpl_bug38694.test:
  A new test to check if a delay at the termination phase of slave threads
  could cause any issue.
sql/slave.cc:
  The unguarded read of the running status is removed. Its reading is done in
  terminate_slave_thread() at time run_lock is taken;
  Calling terminate_slave_threads(skip_lock := !need_slave_mutex) in the failing branch of start_slave_threads() which is bug#38716 issue.
sql/slave.h:
  removing terminate_slave_thread() out of the global interface scope.

In order to define the --slave-load-tmpdir, the init_relay_log_file()
was calling fn_format(MY_PACK_FILENAME) which internally was indirectly
calling strmov_overlapp() (through pack_dirname) and the following
warning message was being printed out while running in Valgrind:
"source and destination overlap in strcpy".

We fixed the issue by removing the flag MY_PACK_FILENAME as it was not
necessary. In a nutshell, with this flag the function fn_format() tried
to replace a directory by either "~", "." or "..". However, we wanted
exactly to remove such strings.

In this patch, we also refactored the functions init_relay_log_file()
and check_temp_dir(). The former was refactored to call the fn_format()
with the flag MY_SAFE_PATH along with the MY_RETURN_REAL_PATH,  in order
to avoid issues with long directories and return an absolute path,
respectively. The flag MY_SAFE_UNPACK_FILENAME was removed too as it was
responsible for removing "~...

We didn't expect "error: no error", although this is
in fact a legitimate state (if something is erroneous
on the master, but not on the slave, e.g. INSERT fails
on master due to UNIQUE constraint which does not exist
on slave).

We now list the ignore for "0: no error" the same way
as any other ignore; moreover, if no or an empty
--slave-skip-errors is passed at start-up, we show
"OFF" instead of empty list, as intended. (The code
for that was there, but was only run for the empty-
argument case, even if it subsequently tested for
both conditions.) 

mysql-test/r/not_embedded_server.result:
  Show that passing no --slave-skip-errors results
  in "OFF" being shown as the variable's value. This
  test's "twin" (also not embedded, but setting
  --slave-skip-errors in its -opt file) lives in
  variables-notembbeded.test.
mysql-test/r/variables-notembedded.result:
  Show that error-ignore 0 is handled just like any other
  ignore. This test's "twin" (also not embedded, but not
  setting --slave-skip-errors in its -opt file) lives in
  not_embbeded_server.test.
mysql-test/t/not_embedded_server.test:
  Show that passing no --slave-skip-errors results
  in "OFF" being shown as the variable's value.
mysql-test/t/variables-notembedded-master.opt:
  Show that error-ignore 0 is handled just like any other
  ignore.
sql/slave.cc:
  - set up error-ignore-info even if --slave-skip-errors
    was not passed at start-up.
  
  - handle error 0 just like any other error.

                              
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

Bug#319  if while a non-transactional slave is replicating a transaction possible problem 

It is impossible to roll back a mixed engines transaction when one of the engine is
non-transaction. In replication that fact is crucial because the slave can not safely
re-apply a transction that was interrupted with STOP SLAVE.

Fixed with making STOP SLAVE not be effective immediately in the case the current
group of replication events has modified a non-transaction table. In order for slave to leave
either the group needs finishing or the user issues KILL QUERY|CONNECTION slave_thread_id.


mysql-test/suite/bugs/r/rpl_bug38205.result:
  bug#38205 non-deterministic part of tests results.
mysql-test/suite/bugs/t/rpl_bug38205.test:
  bug#38205 non-deterministic part of tests.
mysql-test/suite/rpl/r/rpl_start_stop_slave.result:
  bug#38205 deterministic part of tests results.
mysql-test/suite/rpl/t/rpl_start_stop_slave-slave.opt:
  increasing `innodb_lock_wait_timeout' to make the test pass on slow env w/o
  timeout expired issue.
mysql-test/suite/rpl/t/rpl_start_stop_slave.test:
  bug#38205 deterministic part of tests.
sql/log_event.cc:
  Augmenting row-based events applying with the notion of 
  thd->transaction.{all,stmt}.modified_non_trans_table.
  The pair is set and reset according to its specification
  for the mixed transaction processing.
  Particualry, once `modified_non_trans_table' is set in the row-events
  processing loop, it will remain till the commit of the transaction.
sql/slave.cc:
  Consulting `thd->transaction.all.modified_non_trans_table' to decide
  whether to terminate by the sql thread or to continue even though
  the sql thread might have been STOP-ed (rli->abort_slave).

Compiling with debug and assigning an invalid directory to --slave-load-tmpdir
was crashing the slave due to the following assertion DBUG_ASSERT(! is_set() ||
can_overwrite_status). This assertion assumes that a thread can change its
state once (i.e. ok,error, etc) before aborting, cleaning/resuming or completing
its execution unless the overwrite flag (i.e. can_overwrite_status) is true.

The Append_block_log_event::do_apply_event which is responsible for creating
temporary file(s) was not cleaning the thread state. Thus a failure while
trying to create a file in an invalid temporary directory was causing the crash.

To fix the problem we check if the temporary directory is valid before starting
the SQL Thread and reset the thread state before creating a file in
Append_block_log_event::do_apply_event.