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?
if (lock_type == TL_WRITE && table->table->s->version)
DBUG_PRINT("admin", ("removing table from cache"));
const char *old_message=thd->enter_cond(&COND_refresh, &LOCK_open,
"Waiting to get writelock");
On Wed, Dec 28, 2011 at 5:09 AM, Michael Widenius <monty@stripped> wrote:
>>>>>> "Zardosht" == Zardosht Kasheff <zardosht@stripped>
> Zardosht> How can a storage engine allow access to a table by other clients while
> 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
> Zardosht> running an optimize, there is no way for the storage engine to tell
> 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.