An error occurred fetching the project authors.
- 23 Nov, 2009 1 commit
-
-
Konstantin Osipov authored
------------------------------------------------------------- revno: 2877 committer: Davi Arnaut <Davi.Arnaut@Sun.COM> branch nick: 35164-6.0 timestamp: Wed 2008-10-15 19:53:18 -0300 message: Bug#35164: Large number of invalid pthread_attr_setschedparam calls Bug#37536: Thread scheduling causes performance degradation at low thread count Bug#12702: Long queries take 100% of CPU and freeze other applications under Windows The problem is that although having threads with different priorities yields marginal improvements [1] in some platforms [2], relying on some statically defined priorities (QUERY_PRIOR and WAIT_PRIOR) to play well (or to work at all) with different scheduling practices and disciplines is, at best, a shot in the dark as the meaning of priority values may change depending on the scheduling policy set for the process. Another problem is that increasing priorities can hurt other concurrent (running on the same hardware) applications (such as AMP) by causing starvation problems as MySQL threads will successively preempt lower priority processes. This can be evidenced by Bug#12702. The solution is to not change the threads priorities and rely on the system scheduler to perform its job. This also enables a system admin to increase or decrease the scheduling priority of the MySQL process, if intended. Furthermore, the internal wrappers and code for changing the priority of threads is being removed as they are now unused and ancient. 1. Due to unintentional side effects. On Solaris this could artificially help benchmarks as calling the priority changing syscall millions of times is more beneficial than the actual setting of the priority. 2. Where it actually works. It has never worked on Linux as the default scheduling policy SCHED_OTHER only accepts the static priority 0.
-
- 30 Oct, 2009 1 commit
-
-
Sergei Golubchik authored
function/ syntax glob(7) wildcards unit tests
-
- 21 Oct, 2009 1 commit
-
-
Konstantin Osipov authored
2630.39.1, 2630.28.29, 2630.34.3, 2630.34.2, 2630.34.1, 2630.29.29, 2630.29.28, 2630.31.1, 2630.28.13, 2630.28.10, 2617.23.14 and some other minor revisions. This patch implements: WL#4264 "Backup: Stabilize Service Interface" -- all the server prerequisites except si_objects.{h,cc} themselves (they can be just copied over, when needed). WL#4435: Support OUT-parameters in prepared statements. (and all issues in the initial patches for these two tasks, that were discovered in pushbuild and during testing). Bug#39519: mysql_stmt_close() should flush all data associated with the statement. After execution of a prepared statement, send OUT parameters of the invoked stored procedure, if any, to the client. When using the binary protocol, send the parameters in an additional result set over the wire. When using the text protocol, assign out parameters to the user variables from the CALL(@var1, @var2, ...) specification. The following refactoring has been made: - Protocol::send_fields() was renamed to Protocol::send_result_set_metadata(); - A new Protocol::send_result_set_row() was introduced to incapsulate common functionality for sending row data. - Signature of Protocol::prepare_for_send() was changed: this operation does not need a list of items, the number of items is fully sufficient. The following backward incompatible changes have been made: - CLIENT_MULTI_RESULTS is now enabled by default in the client; - CLIENT_PS_MULTI_RESUTLS is now enabled by default in the client.
-
- 16 Oct, 2009 1 commit
-
-
Georgi Kodinov authored
Implemented the server infrastructure for the fix: 1. Added a function LEX_STRING *thd_query_string(THD) to return a LEX_STRING structure instead of char *. This is the function that must be called in innodb instead of thd_query() 2. Did some encapsulation in THD : aggregated thd_query and thd_query_length into a LEX_STRING and made accessor and mutator methods for easy code updating. 3. Updated the server code to use the new methods where applicable.
-
- 14 Oct, 2009 1 commit
-
-
The BINLOG statement was sharing too much code with the slave SQL thread, introduced with the patch for Bug#32407. This caused statements to be logged with the wrong server_id, the id stored inside the events of the BINLOG statement rather than the id of the running server. Fix by rearranging code a bit so that only relevant parts of the code are executed by the BINLOG statement, and the server_id of the server executing the statements will not be overrided by the server_id stored in the 'format description BINLOG statement'.
-
- 09 Oct, 2009 1 commit
-
-
Andrei Elkin authored
-
- 02 Oct, 2009 1 commit
-
-
He Zhenxing authored
There are three internal status for slave I/O thread, both MYSQL_SLAVE_RUN_NOT_CONNECT and MYSQL_SLAVE_NOT_RUN are reported as 'No' for Slave_IO_running of command SHOW SLAVE STATUS. Change MYSQL_SLAVE_RUN_NOT_CONNECT to be reported as 'Connecting'.
-
- 01 Oct, 2009 1 commit
-
-
Andrei Elkin authored
-
- 30 Sep, 2009 2 commits
-
-
Alfranio Correia authored
NOTE: Backporting the patch to next-mr. The slave was crashing while failing to execute the init_slave() function. The issue stems from two different reasons: 1 - A failure while allocating the master info structure generated a segfault due to a NULL pointer. 2 - A failure while recovering generated a segfault due to a non-initialized relay log file. In other words, the mi->init and rli->init were both set to true before executing the recovery process thus creating an inconsistent state as the relay log file was not initialized. To circumvent such problems, we refactored the recovery process which is now executed while initializing the relay log. It is ensured that the master info structure is created before accessing it and any error is propagated thus avoiding to set mi->init and rli->init to true when for instance the relay log is not initialized or the relay info is not flushed. The changes related to the refactory are described below: 1 - Removed call to init_recovery from init_slave. 2 - Changed the signature of the function init_recovery. 3 - Removed flushes. They are called while initializing the relay log and master info. 4 - Made sure that if the relay info is not flushed the mi-init and rli-init are not set to true. In this patch, we also replaced the exit(1) in the fault injection by DBUG_ABORT() to make it compliant with the code guidelines.
-
Davi Arnaut authored
On Mac OS X or Windows, sending a SIGHUP to the server or a asynchronous flush (triggered by flush_time), would cause the server to crash. The problem was that a hook used to detach client API handles wasn't prepared to handle cases where the thread does not have a associated session. The solution is to verify whether the thread has a associated session before trying to detach a handle.
-
- 29 Sep, 2009 3 commits
-
-
Alfranio Correia authored
NOTE: Backporting the patch to next-mr. The fix proposed in BUG#35542 and BUG#31665 introduces a performance issue when fsyncing the master.info, relay.info and relay-log.bin* after #th events. Although such solution has been proposed to reduce the probability of corrupted files due to a slave-crash, the performance penalty introduced by it has made the approach impractical for highly intensive workloads. In a nutshell, the option --syn-relay-log proposed in BUG#35542 and BUG#31665 simultaneously fsyncs master.info, relay-log.info and relay-log.bin* and this is the main source of performance issues. This patch introduces new options that give more control to the user on what should be fsynced and how often: 1) (--sync-master-info, integer) which syncs the master.info after #th event; 2) (--sync-relay-log, integer) which syncs the relay-log.bin* after #th events. 3) (--sync-relay-log-info, integer) which syncs the relay.info after #th transactions. To provide both performance and increased reliability, we recommend the following setup: 1) --sync-master-info = 0 eventually the operating system will fsync it; 2) --sync-relay-log = 0 eventually the operating system will fsync it; 3) --sync-relay-log-info = 1 fsyncs it after every transaction; Notice, that the previous setup does not reduce the probability of corrupted master.info and relay-log.bin*. To overcome the issue, this patch also introduces a recovery mechanism that right after restart throws away relay-log.bin* retrieved from a master and updates the master.info based on the relay.info: 4) (--relay-log-recovery, boolean) which enables a recovery mechanism that throws away relay-log.bin* after a crash. However, it can only recover the incorrect binlog file and position in master.info, if other informations (host, port password, etc) are corrupted or incorrect, then this recovery mechanism will fail to work.
-
Andrei Elkin authored
Improving an error report generating.
-
Andrei Elkin authored
backporting from 6.0 code base to 5.1.
-
- 26 Sep, 2009 1 commit
-
-
He Zhenxing authored
Backporting BUG#44058 BUG#42244 BUG#45672 BUG#45673 Backporting BUG#45819 BUG#45973 BUG#39012
-
- 23 Sep, 2009 2 commits
-
-
Staale Smedseng authored
with gcc 4.3.2 Cleaning up warnings not present in 5.0.
-
Alexander Nozdrin authored
when compiled with Sun Studio compiler). The thing is that Sun Studio compiler calls destructor of stack objects when pthread_exit() is called. That triggered an assertion in DBUG_ENTER()/DBUG_RETURN() validation logic (if DBUG_ENTER() is used in the beginning of function, all returns should be replaced by DBUG_RETURN/DBUG_VOID_RETURN macros). A fix is to explicitly use DBUG_LEAVE macro.
-
- 18 Sep, 2009 1 commit
-
-
But there is no Last_IO_Error reported. On the master, if a binary log event is larger than max_allowed_packet, ER_MASTER_FATAL_ERROR_READING_BINLOG and the specific reason of this error is sent to a slave when it requests a dump from the master, thus leading the I/O thread to stop. On a slave, the I/O thread stops when receiving a packet larger than max_allowed_packet. In both cases, however, there was no Last_IO_Error reported. This patch adds code to report the Last_IO_Error and exact reason before stopping the I/O thread and also reports the case the out memory pops up while handling packets from the master.
-
- 10 Sep, 2009 1 commit
-
-
Marc Alff authored
WL#2265 (RESIGNAL) Manual merge of SIGNAL and RESIGNAL to mysql-trunk-signal, plus required dependencies.
-
- 19 Aug, 2009 1 commit
-
-
Alfranio Correia authored
If the SQL Thread fails to execute an event due to a temporary error (e.g. ER_LOCK_DEADLOCK) and the option "--slave_transaction_retries" is set the SQL Thread should not be aborted and the transaction should be restarted from the beginning and re-executed. Unfortunately, a wrong interpretation of the THD::is_fatal_error was preventing this behavior. In a nutshell, "this variable is set to TRUE if an execution of a compound statement cannot continue. In particular, it is used to disable access to the CONTINUE or EXIT handlers of stored routines. So even temporary errors may have this variable set. To fix the bug, we have done what follows: DBUG_ENTER("has_temporary_error"); - if (thd->is_fatal_error) - DBUG_RETURN(0); - DBUG_EXECUTE_IF("all_errors_are_temporary_errors", if (thd->main_da.is_error()) {
-
- 13 Aug, 2009 1 commit
-
-
Davi Arnaut authored
Bug#45243: crash on win in sql thread clear_tables_to_lock() -> free() Bug#45242: crash on win in mysql_close() -> free() Bug#45238: rpl_slave_skip, rpl_change_master failed (lost connection) for STOP SLAVE Bug#46030: rpl_truncate_3innodb causes server crash on windows Bug#46014: rpl_stm_reset_slave crashes the server sporadically in pb2 When killing a user session on the server, it's necessary to interrupt (notify) the thread associated with the session that the connection is being killed so that the thread is woken up if waiting for I/O. On a few platforms (Mac, Windows and HP-UX) where the SIGNAL_WITH_VIO_CLOSE flag is defined, this interruption procedure is to asynchronously close the underlying socket of the connection. In order to enable this schema, each connection serving thread registers its VIO (I/O interface) so that other threads can access it and close the connection. But only the owner thread of the VIO might delete it as to guarantee that other threads won't see freed memory (the thread unregisters the VIO before deleting it). A side note: closing the socket introduces a harmless race that might cause a thread attempt to read from a closed socket, but this is deemed acceptable. The problem is that this infrastructure was meant to only be used by server threads, but the slave I/O thread was registering the VIO of a mysql handle (a client API structure that represents a connection to another server instance) as a active connection of the thread. But under some circumstances such as network failures, the client API might destroy the VIO associated with a handle at will, yet the VIO wouldn't be properly unregistered. This could lead to accesses to freed data if a thread attempted to kill a slave I/O thread whose connection was already broken. There was a attempt to work around this by checking whether the socket was being interrupted, but this hack didn't work as intended due to the aforementioned race -- attempting to read from the socket would yield a "bad file descriptor" error. The solution is to add a hook to the client API that is called from the client code before the VIO of a handle is deleted. This hook allows the slave I/O thread to detach the active vio so it does not point to freed memory.
-
- 24 Jul, 2009 1 commit
-
-
Gleb Shchepa authored
procedures causes crashes! The problem of that bugreport was mostly fixed by the patch for bug 38691. However, attached test case focused on another crash or valgrind warning problem: SHOW PROCESSLIST query accesses freed memory of SP instruction that run in a parallel connection. Changes of thd->query/thd->query_length in dangerous places have been guarded with the per-thread LOCK_thd_data mutex (the THD::LOCK_delete mutex has been renamed to THD::LOCK_thd_data).
-
- 17 Jul, 2009 1 commit
-
- 16 Jul, 2009 1 commit
-
-
The "get_master_version_and_clock(...)" function in sql/slave.cc ignores error and passes directly when queries fail, or queries succeed but the result retrieved is empty. The "get_master_version_and_clock(...)" function should try to reconnect master if queries fail because of transient network problems, and fail otherwise. The I/O thread should print a warning if the some system variables do not exist on master (very old master)
-
- 06 Jul, 2009 1 commit
-
-
Alfranio Correia authored
timeout In STMT and MIXED modes, a statement that changes both non-transactional and transactional tables must be written to the binary log whenever there are changes to non-transactional tables. This means that the statement gets into the binary log even when the changes to the transactional tables fail. In particular , in the presence of a failure such statement is annotated with the error number and wrapped in a begin/rollback. On the slave, while applying the statement, it is expected the same failure and the rollback prevents the transactional changes to be persisted. Unfortunately, statements that fail due to concurrency issues (e.g. deadlocks, timeouts) are logged in the same way causing the slave to stop as the statements are applied sequentially by the SQL Thread. To fix this bug, we automatically ignore concurrency failures on the slave. Specifically, the following failures are ignored: ER_LOCK_WAIT_TIMEOUT, ER_LOCK_DEADLOCK and ER_XA_RBDEADLOCK.
-
- 29 Jun, 2009 1 commit
-
-
Staale Smedseng authored
-
- 23 Jun, 2009 1 commit
-
-
Andrei Elkin authored
The reason for the crash was rotate_relay_log (mi=0x0) did not verify the passed value of active_mi. There are more cases where active_mi is supposed to be non-zero e.g change_master(), stop_slave(), and it's reasonable to protect from a similar crash all of them with common fixes. Fixed with spliting end_slave() in slave threads release and slave data clean-up parts (a new close_active_mi()). The new function is invoked at the very end of close_connections() so that all users of active_mi are proven to have left.
-
- 16 Jun, 2009 1 commit
-
-
Alfranio Correia authored
This is a backport of BUG#43076.
-
- 09 Jun, 2009 2 commits
-
-
Staale Smedseng authored
with gcc 4.3.2 Compiling MySQL with gcc 4.3.2 and later produces a number of warnings, many of which are new with the recent compiler versions. This bug will be resolved in more than one patch to limit the size of changesets. This is the first patch, fixing a number of the warnings, predominantly "suggest using parentheses around && in ||", and empty for and while bodies.
-
Staale Smedseng authored
with gcc 4.3.2 Compiling MySQL with gcc 4.3.2 and later produces a number of warnings, many of which are new with the recent compiler versions. This bug will be resolved in more than one patch to limit the size of changesets. This is the first patch, fixing a number of the warnings, predominantly "suggest using parentheses around && in ||", and empty for and while bodies.
-
- 03 Jun, 2009 1 commit
-
-
Luis Soares authored
The server was not cleaning the last IO error and error number when resetting slave. This patch addresses this issue by backporting into 5.1 part of the patch in BUG 34654. A fix for this issue had already been pushed into 6.0 as part of the aforementioned bug, however the patch also included some refactoring. The fix for 5.1 does not take into account the refactoring part.
-
- 22 May, 2009 1 commit
-
-
Luis Soares authored
stop/start slave When stopping and restarting the slave while it is replicating temporary tables, the server would crash or raise an assertion failure. This was due to the fact that although temporary tables are saved between slave threads restart, the reference to the thread in use (table->in_use) was not being properly updated when the restart happened (it would still reference the old/invalid thread instead of the new one). This patch addresses this issue by resetting the reference to the new slave thread on slave thread restart.
-
- 05 May, 2009 1 commit
-
-
Davi Arnaut authored
-
- 04 May, 2009 1 commit
-
-
Andrei Elkin authored
-
- 28 Apr, 2009 1 commit
-
-
Andrei Elkin authored
The issue of the current bug is unguarded access to mi->slave_running by the shutdown thread calling end_slave() that is bug#29968 (alas happened not to be cross-linked with the current bug) Fixed: with removing the unguarded read of the running status and perform reading it in terminate_slave_thread() at time run_lock is taken (mostly bug#29968 backporting, still with some improvements over that patch - see the error reporting from terminate_slave_thread()). Issue of bug#38716 is fixed here for 5.0 branch as well. Note: There has been a separate artifact identified - a race condition between init_slave() and end_slave() - reported as Bug#44467.
-
- 19 Apr, 2009 1 commit
-
-
Alfranio Correia authored
In order to define the --slave-load-tmpdir, the init_relay_log_file() was calling fn_format(MY_PACK_FILENAME) which internally was indirectly calling strmov_overlapp() (through pack_dirname) and the following warning message was being printed out while running in Valgrind: "source and destination overlap in strcpy". We fixed the issue by removing the flag MY_PACK_FILENAME as it was not necessary. In a nutshell, with this flag the function fn_format() tried to replace a directory by either "~", "." or "..". However, we wanted exactly to remove such strings. In this patch, we also refactored the functions init_relay_log_file() and check_temp_dir(). The former was refactored to call the fn_format() with the flag MY_SAFE_PATH along with the MY_RETURN_REAL_PATH, in order to avoid issues with long directories and return an absolute path, respectively. The flag MY_SAFE_UNPACK_FILENAME was removed too as it was responsible for removing "~", "." or ".." only from the file parameter and we wanted to remove such strings from the directory parameter in the fn_format(). This result is stored in an rli variable, which is then processed by the other function in order to verify if the directory exists and if we are able to create files in it.
-
- 06 Apr, 2009 1 commit
-
-
Tatiana A. Nurnberg authored
We didn't expect "error: no error", although this is in fact a legitimate state (if something is erroneous on the master, but not on the slave, e.g. INSERT fails on master due to UNIQUE constraint which does not exist on slave). We now list the ignore for "0: no error" the same way as any other ignore; moreover, if no or an empty --slave-skip-errors is passed at start-up, we show "OFF" instead of empty list, as intended. (The code for that was there, but was only run for the empty- argument case, even if it subsequently tested for both conditions.)
-
- 05 Apr, 2009 1 commit
-
-
Alfranio Correia authored
RBR was not considering the option --slave-skip-errors. To fix the problem, we are reporting the ignored ERROR(s) as warnings thus avoiding stopping the SQL Thread. Besides, it fixes the output of "SHOW VARIABLES LIKE 'slave_skip_errors'" which was showing nothing when the value "all" was assigned to --slave-skip-errors. @sql/log_event.cc skipped rbr errors when the option skip-slave-errors is set. @sql/slave.cc fixed the output of for SHOW VARIABLES LIKE 'slave_skip_errors'" @test-cases fixed the output of rpl.rpl_idempotency updated the test case rpl_skip_error
-
- 26 Mar, 2009 1 commit
-
-
Andrei Elkin authored
Bug#319 if while a non-transactional slave is replicating a transaction possible problem It is impossible to roll back a mixed engines transaction when one of the engine is non-transaction. In replication that fact is crucial because the slave can not safely re-apply a transction that was interrupted with STOP SLAVE. Fixed with making STOP SLAVE not be effective immediately in the case the current group of replication events has modified a non-transaction table. In order for slave to leave either the group needs finishing or the user issues KILL QUERY|CONNECTION slave_thread_id.
-
- 18 Mar, 2009 1 commit
-
-
Alfranio Correia authored
Compiling with debug and assigning an invalid directory to --slave-load-tmpdir was crashing the slave due to the following assertion DBUG_ASSERT(! is_set() || can_overwrite_status). This assertion assumes that a thread can change its state once (i.e. ok,error, etc) before aborting, cleaning/resuming or completing its execution unless the overwrite flag (i.e. can_overwrite_status) is true. The Append_block_log_event::do_apply_event which is responsible for creating temporary file(s) was not cleaning the thread state. Thus a failure while trying to create a file in an invalid temporary directory was causing the crash. To fix the problem we check if the temporary directory is valid before starting the SQL Thread and reset the thread state before creating a file in Append_block_log_event::do_apply_event.
-
- 11 Feb, 2009 1 commit
-
-
Alfranio Correia authored
Some errors that cause the slave SQL thread to stop are not shown in the Slave_SQL_Error column of "SHOW SLAVE STATUS". Instead, the error is only in the server's error log. That makes it difficult to analyze the error for the user. One example of an error that stops the slave but is not shown by "SHOW SLAVE STATUS" is when @@global.init_slave is set incorrectly (e.g., it contains something that is not valid SQL). Three failures were not correctly reported: 1 - Failures during slave thread initialization 2 - Failures while initializing the relay log position right after starting the slave thread. 3 - Failures while processing queries passed through the init_slave option. This patch fixes the issues by reporting the errors through relay-info->report.
-