The slave threads MUST not care about max_join_size, we start them with

OPTION_BIG_SELECTS.


sql/slave.cc:
  The slave threads MUST not care about max_join_size.
  I can imagine the case of a slave where users can connect and do SELECTs, but
  DBA does not want them to issue crazy SELECTs, but he/she still wants replication
  to work.
  Before, this just printed a warning to the error log (not fatal) but that
  was still annoying.

sql/slave.cc

@@ -1988,7 +1988,14 @@ 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) ;
+  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.
+    */
+    OPTION_BIG_SELECTS ; 
+    
   thd->client_capabilities = CLIENT_LOCAL_FILES;
   thd->real_id=pthread_self();
   pthread_mutex_lock(&LOCK_thread_count);
@@ -2008,9 +2015,6 @@ static int init_slave_thread(THD* thd, SLAVE_THD_TYPE thd_type)
   VOID(pthread_sigmask(SIG_UNBLOCK,&set,&thd->block_signals));
 #endif
 
-  if (thd->variables.max_join_size == HA_POS_ERROR)
-    thd->options |= OPTION_BIG_SELECTS;
-
   if (thd_type == SLAVE_THD_SQL)
     thd->proc_info= "Waiting for the next event in slave queue";
   else