Created by Vlad Lesin and last modified
Get this branch:
bzr branch lp:~vlad-lesin/percona-server/5.6-sql_timeout_twitter
Only Vlad Lesin can upload to this branch. If you are Vlad Lesin please log in for upload directions.

Branch merges

Related bugs

Related blueprints

Branch information

Recent revisions

426. By Vlad Lesin on 2013-09-09

This is implementation of this

The original implementation can be found here:

Current implementation allows to limit query execution time. The limit can be
set with session/global variable MAX_STATEMENT_TIME in milliseconds.
The MAX_STATEMENT_TIME limit can be set with GRANT statement. For example:
GRANT ... TO 'user'@'host' WITH MAX_STATEMENT_TIME 10.

If query execution time exceeds the limit the query will be interrupted and
corresponding error will be sent to client.

See blueprint for more detailed usage explanation.

Separate thread is used to handle timeouts. If MAX_STATEMENT_TIME is not null
each db-thread creates a timer before each query execution and removes it after
that. If timer expires the timer thread is waken up and invokes
THD::awake(THD::KILL_TIMEOUT) which not only sets THD::killed state and awakes
db-thread from sleep on mysys_var->current_cond condition variable
(for example if SLEEP() built-in function is executed) but also invokes
handlerton::kill_connection() for each enabled storage engine plugin.
handlerton::kill_connection() should break query execution inside of storage
engine plugin. Currently handlerton::kill_connection() is implemented for innodb.

The timers itself are based on posix timer_create() function for Linux and
kqueue() for BSD.

425. By Vlad Lesin on 2013-09-09

Bug #1115158 (upstream #64556): Interrupting a query inside InnoDB causes an
unrelated warning 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.

424. By Vlad Lesin on 2013-09-09

Bug #1115048 (upstream 60682): deadlock from thd_security_context

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).

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.