Re: question about locks with optimize table

In this region of code that is locking out other clients, I don't see
table->lock set to TL_WRITE_ALLOW_WRITE, even though store_lock does
so. It does not seem to be working.

Here is the big question. If we change the code somehow such that for
our engine, the below if-clause evaluates to FALSE, would that be ok?

Thanks
-Zardosht

    if (lock_type == TL_WRITE && table->table->s->version)
    {
      DBUG_PRINT("admin", ("removing table from cache"));
      pthread_mutex_lock(&LOCK_open);
      const char *old_message=thd->enter_cond(&COND_refresh, &LOCK_open,
					      "Waiting to get writelock");
      mysql_lock_abort(thd,table->table, TRUE);
      remove_table_from_cache(thd, table->table->s->db.str,
                              table->table->s->table_name.str,
                              RTFC_WAIT_OTHER_THREAD_FLAG |
                              RTFC_CHECK_KILLED_FLAG);

On Wed, Dec 28, 2011 at 5:09 AM, Michael Widenius <[email protected]> wrote:
>
> Hi!
>
>>>>>> "Zardosht" == Zardosht Kasheff <[email protected]> writes:
>
> Zardosht> How can a storage engine allow access to a table by other clients while an
> Zardosht> optimize is running?
>
> Zardosht> I think the issue here is that even if the storage
> Zardosht> engine could theoretically allow access to the table by other clients while
> Zardosht> running an optimize, there is no way for the storage engine to tell MySQL
> Zardosht> that this is ok. Setting the lock type to TL_WRITE_ALLOW_WRITE in
> Zardosht> handler::store_lock does not work
>
>
> By doing it either of these ways:
>
> - Return at once from handler::optimize() and then run optimize in the
>  background in the storage engine.
>
> - Change mysql_admin_table() to check for 'table->lock_type' instead
>  of 'lock_type' in the code.  This should allow the storage engine to
>  change to use TL_WRITE_ALLOW_WRITE in handler::store_lock().
>
> Please check if the later works for you, in which case I will do the
> above change in MariaDB.
>
> Regards,
> Monty

-- 
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe:    http://lists.mysql.com/internals