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 <monty@stripped> wrote:
>
> Hi!
>
>>>>>> "Zardosht" == Zardosht Kasheff <zardosht@stripped>
> 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
