Re: bzr commit into mysql-5.1-bugteam branch (davi:2734) Bug#40536

[Konstantin Osipov]

* Davi Arnaut <Davi.Arnaut@stripped> [09/01/15 13:27]:
>  2734 Davi Arnaut	2009-01-15
>       Bug#40536: SELECT is blocked by INSERT DELAYED waiting on
>                  upgrading lock, even with low_pri
>       
>       The problem is that there is no mechanism to control whether a
>       delayed insert takes a high or low priority lock on a table.
>       
>       The solution is to modify the delayed insert thread ("handler")
>       to take into account the global value of low_priority_updates
>       when taking table locks.

Quite frankly, I thought it's sufficient to remember the value of
the lock once only, when creating the delayed thread.

Reschedule of the write lock is hidden from the user anyway.

> +  delayed_lock= global_system_variables.low_priority_updates ?
> +                                        TL_WRITE_LOW_PRIORITY : TL_WRITE;

Maybe jsut lock at delayed_thd->system_variables instead?

That would avoid a race too, since global_system_variables are
normally operated on under a mutex.


The patch is OK to push if you agree, otherwise let's discuss your
reasons for updating the lock type when rescheduling it.

>    thd_proc_info(&thd, "upgrading lock");
> -  if (thr_upgrade_write_delay_lock(*thd.lock->locks))
> +  if (thr_upgrade_write_delay_lock(*thd.lock->locks, delayed_lock))
>    {

--