From 668f35b7d5a1e9dd77998af4e84df2d3b8f8d56f Mon Sep 17 00:00:00 2001 From: unknown Date: Mon, 24 May 2004 18:46:49 +0200 Subject: [PATCH] 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). --- sql/slave.cc | 12 ++++++++---- 1 file 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);