I committed the same changeset in my tree yesterday, but broke the tree since,

so I commit again in a fresh tree.
Fix for bug#763 (Relay_log_space too big by 4 bytes),
plus comments and DBUG_PRINT, and we don't start replication
if --bootstrap.


mysql-test/r/rpl_log.result:
  Result update
mysql-test/r/rpl_log_pos.result:
  Result update
sql/mysqld.cc:
  Don't start replication if in bootstrap mode (bootstrap isn't supposed to have
  several threads).
sql/slave.cc:
  Fix for bug 763 (Relay_log_space too big by 4 bytes).
  A DBUG_PRINT.
sql/sql_acl.cc:
  Replaced a return by DBUG_RETURN (happened to find this reading a debug log).
sql/sql_repl.cc:
  A comment.

1 files changed, 19 insertions, 0 deletions

diff --git a/sql/sql_repl.cc b/sql/sql_repl.cc
index bf4b1eb0c70..8fb82798a45 100644
--- a/sql/sql_repl.cc
+++ b/sql/sql_repl.cc
@@ -796,6 +796,25 @@ err:
   DBUG_RETURN(error);
 }
 
+/*
+
+  Kill all Binlog_dump threads which previously talked to the same slave
+  ("same" means with the same server id). Indeed, if the slave stops, if the
+  Binlog_dump thread is waiting (pthread_cond_wait) for binlog update, then it
+  will keep existing until a query is written to the binlog. If the master is
+  idle, then this could last long, and if the slave reconnects, we could have 2
+  Binlog_dump threads in SHOW PROCESSLIST, until a query is written to the
+  binlog. To avoid this, when the slave reconnects and sends COM_BINLOG_DUMP,
+  the master kills any existing thread with the slave's server id (if this id is
+  not zero; it will be true for real slaves, but false for mysqlbinlog when it
+  sends COM_BINLOG_DUMP to get a remote binlog dump).
+
+  SYNOPSIS
+    kill_zombie_dump_threads()
+    slave_server_id     the slave's server id
+
+*/
+  
 
 void kill_zombie_dump_threads(uint32 slave_server_id)
 {