value are zero, an invalid password might be accepted.
Restore code that stores the master binary log position of a slave in InnoDB's data file. Like in earlier MySQL versions, if a slave crashes, the name and position of the slave in relation to the master binary log file is printed after crash recovery.
Introduce status variables that provide counters for the various flushing-related tasks performed by InnoDB. For example, these counters provide information about the number of pages scanned and flushed from the flush and LRU lists. Also, there are counters for the number of pages flushed by the background thread.
The internal counter for the number of pages flushed as part of LRU flushing is being incremented twice, once in buf_flush_LRU_list_batch() and again in buf_flush_common(). This might lead to an incorrect calculation of the rate at which LRU flush is happening, which might later affect the statistics associated with adaptive flushing.
…AVE, COM_BEGIN IS PROBLEM: -------- When binary log statements are replayed on the slave, BEGIN is represented in com_counters but COMMIT is not. Similarly in 'ROW' based replication 'INSERT','UPDATE',and 'DELETE' com_counters are not getting incremented when the binary log statements are replayed at slave. ANALYSIS: --------- In 'ROW' based replication for COMMIT,INSERT,UPDATE and DELETE operations following special events are invoked. Xid_log_event,Write_rows_log_event,Update_rows_log_event,Update_rows_log_event. The above mentioned events doesn't go through the parser where the 'COM_COUNTERS' are incremented. FIX: ----- Increment statements are added at appropriate events. Respective functions are listed below. 'Xid_log_event::do_apply_event' 'Write_rows_log_event::do_before_row_operations' 'Update_rows_log_event::do_before_row_operations' 'Delete_rows_log_event::do_before_row_operations' --BZR-- revision-id: email@example.com property-branch-nick: Bug12662190 property-file-info: ld7:file_id65:sp1f-log_event.cc-19700101030959-msmqlflsngxosswid2hpzxly5vfqdddc7:message119:Added code to increment counts for 'COM_INSERT','COM_UPDATE', property-file-info: 'COM_DELETE' and 'COM_COMMIT'during ROW based replicaiton4:path16:sql/log_event.ccee testament3-sha1: 03a97ebea95b3d62ad79b50a08cc607f81cdb5ec
of flushed pages The problem is that the internal counter for the number of flushed pages (srv_buf_pool_flushed) was being incremented twice, once in buf_flush_batch() and again in buf_flush_common().
crash dump information when the server process (mysqld) crashes. The minidump file generated by breakpad contains a list of the executable and shared libraries loaded in the process, the state of the processor register and a stack trace for each thread, and miscellaneous information about the system and the reason for the dump. Minidumps are significantly smaller than core files, making them more practical for collection and processing. The option minidump_dir can be used to specify the path name of the directory in which to store minidumps. Also, a minidump can be generated at runtime by requesting the server to dump debug information with the mysqladmin debug command.
thread will flush dirty pages from the buffer pool if there is I/O bandwidth available for background tasks.
into MYSQL-51 and raise the Twitter version to t5. Conflicts: VERSION storage/innobase/handler/ha_innodb.cc
…ning to be raised Interrupting a statement (with KILL QUERY) that is executing inside InnoDB leads to an unrelated warning being raised in the context of the connection whose statement was interrupted.
Extend testing of the maximum execution time for statements.
Set an appropriate error status when a statement is killed. The error status to be set varies depending on the killed state.
Introduce status variables that provide counters for the number of statements that are timed-limited (max_statement_time_set), for statements that exceeded the maximum execution time (max_statement_time_exceeded) and for failed attempts to set the maximum execution time (max_statement_time_set_failed).
Introduce an account resource limit named MAX_STATEMENT_TIME that can be used to set the default maximum execution time for any statement issued under a given account. That is, the max_statement_time session variable is initialized at connect time using the current value of the equally named resource limit. The MAX_STATEMENT_TIME limit can be set with a CREATE USER or GRANT statement. For example, GRANT ... TO 'user'@'host' WITH MAX_STATEMENT_TIME 10. The server stores the specified value for an account in the max_statement_time column of the user table row corresponding to the account. Given that the max_statement_time variable is initialized using the limit value, the global counterpart of the variable is removed.
Implement an option in the query specification to set the maximum execution time for a SELECT statement. Using the MAX_STATEMENT_TIME=N option, a user is able to specify the maximum execution time (in milliseconds) for a SELECT statement. For example, SELECT MAX_STATEMENT_TIME=10 * FROM table. The source value (N) can only be an integer literal. The option is intended mainly for queries and is not supported if the SELECT statement where the option is used is not a top-level statement (e.g. a subquery). Also, the MAX_STATEMENT_TIME option takes precedence over @@max_statement_time.
Introduce a server-side time limit for the execution of statements. This feature works by interrupting the execution of statements that take over a specified number of milliseconds to complete. After the specified number of milliseconds has passed, the server attempts to abort the statement without affecting the session (connection) itself. The implementation is optimized for the case where a statement finishes executing before reaching the time limit. Also, because the timeout event is an asynchronous operation to the statement being executed, it is possible that a given statement may not be interrupted immediatelyafter the time limit is exceeded. The maximum execution time can be set with the max_statement_time variable. Using the @@max_statement_time variable a user should be able to specify the maximum execution time for any statement. The variable value is based on a unsigned 64 bits long integer, which represents milliseconds. An infinite timeout is represented by a zero value, meaning that no timeout value is set. Lastly, the maximum execution time only applies to top-level statements or queries; compound statements are treated as a regular component of the top-level statement.
Allow threads waiting inside a storage engine to be interrupted if the connection or statement is terminated. This is a prerequisite for implementing server-side statement timeout support with granularity of milliseconds. For example, due to the way that the InnoDB background lock timeout thread works, interrupted transactions are only detected once every second.
Introduce an implementation of per-thread timers. The API can be used to create one-shot timers that use a monotonically increasing clock as the timing base. A timer expires in a given amount of time (in milliseconds) from when the timer is armed. Upon timer expiration, a given callback function is invoked in a separate thread. Timers can also be cancelled (disarmed) and provide an indication of the state (signaled or non-signaled) of the timer at the time of cancellation. The timer API is currently only implemented on Linux and Mac OS X.
Make the slave options --replicate-* dynamic variables so that these options can be changed dynamically while the server is running, which enables users to modify replication filtering rules without having to stop and restart the server. This is accomplished by just requiring that the slave threads are stopped when these options are set dynamically. Since filtering rules are only used by the SQL slave thread, setting them while the thread is not running avoids the need for locking.
The problem is a circular wait condition when providing information about the internal state of InnoDB. When printing information about active transactions, InnoDB holds the kernel mutex (so that transactions do not disappear) and calls back into the server to get a description (in particular, the query) of every session that is associated with a transaction. Since these sessions might be executing unrelated statements, a per-session lock is taken so that the query string can be safely copied. This lock order poses a problem because there might be cases, specially when processing a KILL statement, where the per- session lock is acquired before attempting to acquire locks that might also be acquired by InnoDB while holding the kernel mutex. In order to avoid this problematic lock order, the query of a session associated with an active transaction is no longer displayed in the output of SHOW ENGINE INNODB STATUS. There query now is only printed if a session is describing itself (that is, if the session to be described belongs to the calling thread).
mtr tests. This is a followup to firstname.lastname@example.org which added a deprecation notice to ignore-builtin-innodb --BZR-- revision-id: email@example.com property-branch-nick: mysql-5.5 testament3-sha1: 749b135e849431f7c9e5a58cc5317acd5c5a241b
This is part of Bug#13586262 INNODB - HIBISCUS: ISSUE DEPRECATION WARNINGS FOR VARIABLES Reviewed by: Mark Alff --BZR-- revision-id: firstname.lastname@example.org property-branch-nick: mysql-5.5 testament3-sha1: 0a5ffb78b5f24d9e3c3804e6b7eb27e983306665