…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).
Currently using innodb_max_dirty_pages_pct especially with a large innodb_io_capacity does not enforce any lower limit on the number of dirty pages, and this can increase the number of writes dramatically. While normally this would be OK (flush if you can) this is not desirable behavior on SSDs where write lifetime is limited. In order to reduce and control the frequency of write requests to SSD, this change introduces a new variable named innodb_flush_dirty_pages_age which can be used to set the minimum age of dirty pages to be flushed from the buffer pool if the number of dirty pages is below the maximum percentage. This impacts the frequency with which frequently modified pages are flushed, which can help reduce IO load in systems with frequently modified pages (hot spots).
…ace files Add the ability to extend the tablespace of a table to be at least X pages long if it's smaller. If the tablespace is large enough already, nothing changes. The minimum number of pages can be specified using the table option MIN_PAGES in an ALTER TABLE statement. Extending the tablespace is an in-place operation that does not require a temporary table.
…ace files Add the ability to specific through MIN_PAGES the initial size, in pages, of per-table tablespaces. The option is only meaningful if innodb_file_per_table is enabled. If the initial size is not large enough to contain required metadata, the tablespace will be extended to the required size. If the MIN_PAGES option is not specified, InnoDB uses the minimum size possible. In order to retain forward compatibility in FRMs, MIN_PAGES is implemented as an alias for MIN_ROWS. Using MIN_ROWS has the same effect as MIN_PAGES. If the MIN_PAGES option is used in a CREATE TABLE statement that is logged to the binary log, the MIN_PAGES option is also used in the statement that is sent to slaves.
Fix tablespace bounds checking, the offset of the last page is the tablespace size minus one.
…onfig --cflags This bug is actually a symptom of a much deeper problem. When building OS X universal binaries, the size of certain types might vary across architectures. Use architecture-to-size mapping to properly detect the size of time_t. This should fix a failure of the timezone test case.
Disable mysql_plugin as it keeps getting broken by upstream.
Raise the Twitter version to t4. Conflicts: VERSION
ERROR LOG Fixed error meesage --BZR-- revision-id: email@example.com property-branch-nick: mysql-5.5 testament3-sha1: 5b45601e01652e3449586e6aeb51b81ad2fe1166
…MYSQLCLIENT.A +get_tty_password this is the only external symbol in get_password.c, which is explicitly listed in CLIENT_SOURCES +handle_options this is in mysys/my_getopt.c adding this sysmbol pulls in the other externals: T getopt_compare_strings T getopt_double_limit_value T getopt_ll_limit_value T getopt_ull_limit_value T handle_options T my_cleanup_options T my_getopt_register_get_addr T my_print_help T my_print_variables --BZR-- revision-id: firstname.lastname@example.org property-branch-nick: 5.5 testament3-sha1: 8bc7f0666fae1ff7b3863c5a69e4cf2861b7476a
specific old versions The problem is that the "obsoletes" property of a newer MySQL-server package interferes with the installation of older (obsoleted) MySQL packages from different repositories. For example, yum will replace a MySQL-server-community package with a MySQL-server package if one of the repositories contains a MySQL-server package that obsoletes the MySQL-server-community package. In order to avoid any obsoletes processing logic, the property is simply removed. Since upgrades across major MySQL versions is not supported, this should have no significant impact.
--BZR-- revision-id: email@example.com property-branch-nick: mysql-5.5 property-file-info: ld7:file_id65:2@16c675df-0fcb-4bc9-8058-dcc011a37293:trunk%2Fibuf%2Fibuf0ibuf.c7:message25:Cast to avoid gcc warning4:path33:storage/innobase/ibuf/ibuf0ibuf.cee testament3-sha1: 9ba81d8c32257cc718e1b1c820c5e5366754d4be
… > 1 This fix does not remove the underlying cause of the assertion failure. It just works around the problem, allowing a corrupted secondary index to be fixed by DROP INDEX and CREATE INDEX (or in the worst case, by re-creating the table). ibuf_delete(): If the record to be purged is the last one in the page or it is not delete-marked, refuse to purge it. Instead, write an error message to the error log and let a debug assertion fail. ibuf_set_del_mark(): If the record to be delete-marked is not found, display some more information in the error log and let a debug assertion fail. row_undo_mod_del_unmark_sec_and_undo_update(), row_upd_sec_index_entry(): Let a debug assertion fail when the record to be delete-marked is not found. buf_page_print(): Add ut_ad(0) so that corruption will be more prominent in stress testing with debug binaries. Add ut_ad(0) here and there where corruption is noticed. btr_corruption_report(): Display some data on page_is_comp() mismatch. btr_assert_not_corrupted(): A wrapper around btr_corruption_report(). Assert that page_is_comp() agrees with the table flags. rb:911 approved by Inaam Rana --BZR-- revision-id: firstname.lastname@example.org property-branch-nick: mysql-5.5 testament3-sha1: b8e923031f7ecc314ac2901f843a844406571949