MySQL Bugs: #56780: docs don't match code for table_lock_wait

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:	None
Category:	MySQL Server: General	Severity:	S4 (Feature request)
Version:	5.1.47	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	table_lock_wait_timeout

Description:
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
        TL_UNLOCK).
      - 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

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.

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.

See also bug #41949

Mark,

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

That would work if it were used in my case. I assume it does. But I won't download 5.5 to confirm.