bk commit into 5.1 tree (mats:1.2479) BUG#25688

[Mats Kindahl]

Below is the list of changes that have just been committed into a local
5.1 repository of mats. When mats does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html

ChangeSet@stripped, 2007-03-28 15:19:18+02:00, mats@romeo.(none) +2 -0
  BUG#25688 (RBR: circular replication may cause STMT_END_F flags to be
  skipped):
  
  By moving statement end actions from Rows_log_event::do_apply_event() to
  Rows_log_event::do_update_pos() they will always be executed, even if
  Rows_log_event::do_apply_event() is skipped because the event originated
  at the same server. This because Rows_log_event::do_update_pos() is always
  executed (unless Rows_log_event::do_apply_event() failed with an error,
  in which case the slave stops with an error anyway). 

  sql/log_event.cc@stripped, 2007-03-28 15:19:11+02:00, mats@romeo.(none) +37 -30
    Moving statement end actions from Rows_log_event::do_apply_event() to
    Rows_log_event::do_update_pos().

  sql/log_event.h@stripped, 2007-03-28 15:19:12+02:00, mats@romeo.(none) +1 -0
    Adding Rows_log_event::do_update_pos().

# This is a BitKeeper patch.  What follows are the unified diffs for the
# set of deltas contained in the patch.  The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User:	mats
# Host:	romeo.(none)
# Root:	/home/bk/b25688-mysql-5.1-rpl

--- 1.276/sql/log_event.cc	2007-03-28 15:19:26 +02:00
+++ 1.277/sql/log_event.cc	2007-03-28 15:19:27 +02:00
@@ -6164,6 +6164,37 @@
     DBUG_RETURN(error);
   }
 
+  if (table && get_flags(STMT_END_F) &&
+      (table->s->primary_key == MAX_KEY) && !cache_stmt)
+  {
+    /*
+      ------------ Temporary fix until WL#2975 is implemented ---------
+
+      This event is not the last one (no STMT_END_F). If we stop now
+      (in case of terminate_slave_thread()), how will we restart? We
+      have to restart from Table_map_log_event, but as this table is
+      not transactional, the rows already inserted will still be
+      present, and idempotency is not guaranteed (no PK) so we risk
+      that repeating leads to double insert. So we desperately try to
+      continue, hope we'll eventually leave this buggy situation (by
+      executing the final Rows_log_event). If we are in a hopeless
+      wait (reached end of last relay log and nothing gets appended
+      there), we timeout after one minute, and notify DBA about the
+      problem.  When WL#2975 is implemented, just remove the member
+      st_relay_log_info::last_event_start_time and all its occurences.
+    */
+    const_cast<RELAY_LOG_INFO*>(rli)->last_event_start_time= time(0);
+  }
+
+  DBUG_RETURN(0);
+}
+
+int
+Rows_log_event::do_update_pos(RELAY_LOG_INFO *rli)
+{
+  DBUG_ENTER("Rows_log_event::do_update_pos");
+  int error= 0;
+
   if (get_flags(STMT_END_F))
   {
     /*
@@ -6203,7 +6234,7 @@
     */
 
     thd->reset_current_stmt_binlog_row_based();
-    const_cast<RELAY_LOG_INFO*>(rli)->cleanup_context(thd, 0);
+    rli->cleanup_context(thd, 0);
 
     if (error == 0)
     {
@@ -6219,38 +6250,14 @@
     }
     else
       slave_print_msg(ERROR_LEVEL, rli, error,
-                      "Error in %s event: commit of row events failed, "
-                      "table `%s`.`%s`",
-                      get_type_str(), table->s->db.str, 
-                      table->s->table_name.str);
-    DBUG_RETURN(error);
-  }
-
-  if (table && (table->s->primary_key == MAX_KEY) && !cache_stmt)
-  {
-    /*
-      ------------ Temporary fix until WL#2975 is implemented ---------
-
-      This event is not the last one (no STMT_END_F). If we stop now
-      (in case of terminate_slave_thread()), how will we restart? We
-      have to restart from Table_map_log_event, but as this table is
-      not transactional, the rows already inserted will still be
-      present, and idempotency is not guaranteed (no PK) so we risk
-      that repeating leads to double insert. So we desperately try to
-      continue, hope we'll eventually leave this buggy situation (by
-      executing the final Rows_log_event). If we are in a hopeless
-      wait (reached end of last relay log and nothing gets appended
-      there), we timeout after one minute, and notify DBA about the
-      problem.  When WL#2975 is implemented, just remove the member
-      st_relay_log_info::last_event_start_time and all its occurences.
-    */
-    const_cast<RELAY_LOG_INFO*>(rli)->last_event_start_time= time(0);
+                      "Error in %s event: commit of row events failed",
+                      get_type_str());
   }
 
-  DBUG_ASSERT(error == 0);
-  thd->clear_error();
+  if (error == 0)
+    error= Log_event::do_update_pos(rli);
 
-  DBUG_RETURN(0);
+  DBUG_RETURN(error);
 }
 
 #endif /* !defined(MYSQL_CLIENT) && defined(HAVE_REPLICATION) */

--- 1.139/sql/log_event.h	2007-03-28 15:19:27 +02:00
+++ 1.140/sql/log_event.h	2007-03-28 15:19:27 +02:00
@@ -2215,6 +2215,7 @@
 
 #if !defined(MYSQL_CLIENT) && defined(HAVE_REPLICATION)
   virtual int do_apply_event(RELAY_LOG_INFO const *rli);
+  virtual int do_update_pos(RELAY_LOG_INFO *rli);
 
   /*
     Primitive to prepare for a sequence of row executions.