Bug #56780 docs don't match code for table_lock_wait_timeout
Submitted: 14 Sep 2010 21:24 Modified: 15 Sep 2010 7:08
Reporter: Mark Callaghan Email Updates:
Status: Verified Impact on me:
Category:MySQL Server: General Severity:S4 (Feature request)
Version:5.1.47 OS:Any
Assigned to: CPU Architecture:Any
Tags: table_lock_wait_timeout

[14 Sep 2010 21:24] Mark Callaghan
The docs at http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_table_lock_wait... state:
This variable is unused.

The code in mysqld.cc states:

  {"table_lock_wait_timeout", OPT_TABLE_LOCK_WAIT_TIMEOUT,
   "Timeout in seconds to wait for a table level lock before returning an "
   "error. Used only if the connection has active cursors.",
   &table_lock_wait_timeout, &table_lock_wait_timeout,
   0, GET_ULONG, REQUIRED_ARG, 50, 1, 1024 * 1024 * 1024, 0, 1, 0},

How to repeat:
The variable table_lock_wait_timeout is used in mysys/thr_lock.c

  /* Set up control struct to allow others to abort locks */
  thread_var->current_mutex= &data->lock->mutex;
  thread_var->current_cond=  cond;
  data->cond= cond;

  if (can_deadlock)
    set_timespec(wait_timeout, table_lock_wait_timeout);
  while (!thread_var->abort || in_wait_list)
    int rc= (can_deadlock ?
             pthread_cond_timedwait(cond, &data->lock->mutex,
                                    &wait_timeout) :
             pthread_cond_wait(cond, &data->lock->mutex));
      We must break the wait if one of the following occurs:
      - the connection has been aborted (!thread_var->abort), but
        this is not a delayed insert thread (in_wait_list). For a delayed
        insert thread the proper action at shutdown is, apparently, to
        acquire the lock and complete the insert.
      - the lock has been granted (data->cond is set to NULL by the granter),
        or the waiting has been aborted (additionally data->type is set to
      - the wait has timed out (rc == ETIMEDOUT)
      Order of checks below is important to not report about timeout
      if the predicate is true.

Suggested fix:
Update the docs
[14 Sep 2010 21:47] Davi Arnaut
IIRC, it is really "unused" (dead code actually). can_deadlock is true only when there are non-materialized cursors, which in turn was never fully implemented and is dead code. The whole stuff was removed in 5.5.
[14 Sep 2010 22:10] Mark Callaghan
Can we convert this to a feature request? I want a variable that lets me specify a timeout for the amount of time a thread blocks in open_tables -> open_table -> wait_for_condition.  For example, if ALTER TABLE is running then any session that tries to use that table gets stuck there. Even if wait_for_condition is changed to use a pthread_cond_timedwait, then the thread gets stuck in the loop open_tables->open_table->wait_for_condition. 

So I need both a timed wait in wait_for_condition and changes in open_tables to know when the timeout has expired. I also need faith that nothing is broken when very complex code is changed. Oh, and I have a patch that probably implements this. The patch is trivial. Faith that that change is correct is not.
[14 Sep 2010 23:05] Sveta Smirnova
See also bug #41949
[14 Sep 2010 23:10] Sveta Smirnova

please check if variable lock_wait_timeout in version 5.5 satisfy your needs. Link to the user manual: http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_lock_wait_timeo...
[14 Sep 2010 23:27] Mark Callaghan
That would work if it were used in my case. I assume it does. But I won't download 5.5 to confirm.