diff options
| author | unknown <guilhem@mysql.com> | 2003-08-23 17:41:43 +0200 |
|---|---|---|
| committer | unknown <guilhem@mysql.com> | 2003-08-23 17:41:43 +0200 |
| commit | 89e95d0c2601879ae21fe093d100449098ce3e7e (patch) | |
| tree | bb826cbe50137ba5d6999e9b0283ff7b3e8d35cd | |
| parent | 9438655af97bf6f06512c1bdb4cc97a451b8fbc1 (diff) | |
| download | mariadb-git-89e95d0c2601879ae21fe093d100449098ce3e7e.tar.gz | |
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.
| -rw-r--r-- | sql/slave.cc | 12 |
1 files changed, 8 insertions, 4 deletions
diff --git a/sql/slave.cc b/sql/slave.cc index 10ec0050d05..66068bec45a 100644 --- a/sql/slave.cc +++ b/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 |