1berry/MariaDB-server
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source 
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.
This commit is contained in:
unknown 2003-08-23 17:41:43 +02:00
parent 9438655af9
commit 89e95d0c26
1 changed files with 8 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
sql/slave.cc
View File

@ -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