Fix for BUG#3871: a slave must always replicate a statement, even if it examines more than 4G rows,

so we set SQL_BIG_SELECTS to 1.


sql/slave.cc:
  The slave SQL thread must always have SQL_BIG_SELECTS=1, so that it does not fail to replicate an INSERT SELECT
  examining more than 4 billion rows (for client threads, SQL_BIG_SELECTS is automatically set to 1 if
  max_join_size is 4G, but that's in handle_one_connection, so not for the slave thread).

1 files changed, 8 insertions, 4 deletions

diff --git a/sql/slave.cc b/sql/slave.cc
index be60b5e6217..2269fc8d8cf 100644
--- a/sql/slave.cc
+++ b/sql/slave.cc
@@ -2130,13 +2130,17 @@ static int init_slave_thread(THD* thd, SLAVE_THD_TYPE thd_type)
   thd->master_access= ~0;
   thd->priv_user = 0;
   thd->slave_thread = 1;
-  thd->options = ((opt_log_slave_updates) ? OPTION_BIN_LOG:0) |
-    OPTION_AUTO_IS_NULL;
   /* 
      It's nonsense to constraint the slave threads with max_join_size; if a
-     query succeeded on master, we HAVE to execute it.
+     query succeeded on master, we HAVE to execute it. So set
+     OPTION_BIG_SELECTS. Setting max_join_size to HA_POS_ERROR is not enough
+     (and it's not needed if we have OPTION_BIG_SELECTS) because an INSERT
+     SELECT examining more than 4 billion rows would still fail (yes, because
+     when max_join_size is 4G, OPTION_BIG_SELECTS is automatically set, but
+     only for client threads.
   */
-  thd->variables.max_join_size= HA_POS_ERROR;    
+  thd->options = ((opt_log_slave_updates) ? OPTION_BIN_LOG:0) |
+    OPTION_AUTO_IS_NULL | OPTION_BIG_SELECTS;
   thd->client_capabilities = CLIENT_LOCAL_FILES;
   thd->real_id=pthread_self();
   pthread_mutex_lock(&LOCK_thread_count);