Fix for BUG#13023: "SQL Thread is up but doesn't move forward". Details in slave.cc;

in short we now record whenever the slave I/O thread ignores a master's event because of its server id,
and use this info in the slave SQL thread to advance Exec_master_log_pos. Because if we
do not, this variable stays at the position of the last executed event, i.e. the last *non-ignored*
executed one, which may not be the last of the master's binlog (and so the slave *looks* behind
the master though it's data-wise it's not).

1 files changed, 3 insertions, 3 deletions

diff --git a/sql/log.cc b/sql/log.cc
index a67f35e30bf..c530f15a84f 100644
--- a/sql/log.cc
+++ b/sql/log.cc
@@ -1028,7 +1028,8 @@ void MYSQL_LOG::new_file(bool need_lock)
         to change base names at some point.
       */
       THD *thd = current_thd; /* may be 0 if we are reacting to SIGHUP */
-      Rotate_log_event r(thd,new_name+dirname_length(new_name));
+      Rotate_log_event r(thd,new_name+dirname_length(new_name),
+                         0, LOG_EVENT_OFFSET, 0);
       r.set_log_pos(this);
       r.write(&log_file);
       bytes_written += r.get_event_len();
@@ -1106,7 +1107,7 @@ bool MYSQL_LOG::appendv(const char* buf, uint len,...)
   
   DBUG_ASSERT(log_file.type == SEQ_READ_APPEND);
   
-  pthread_mutex_lock(&LOCK_log);
+  safe_mutex_assert_owner(&LOCK_log);
   do
   {
     if (my_b_append(&log_file,(byte*) buf,len))
@@ -1125,7 +1126,6 @@ bool MYSQL_LOG::appendv(const char* buf, uint len,...)
   }
 
 err:
-  pthread_mutex_unlock(&LOCK_log);
   if (!error)
     signal_update();
   DBUG_RETURN(error);