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

[Davi Arnaut]

On 1/21/09 9:11 PM, Konstantin Osipov wrote:
> * 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.

Delayed threads won't go away unless explicitly killed. From a user 
perspective, modifying the low priority value in a running server would 
have to involve killing all delayed threads.

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

But if the user says that delayed threads should take low priority 
locks, one would expect that the delayed thread should obey it the next 
time a lock is taken.

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

AFAICS, not for things that can be read atomically.

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

Explained above.

Regards,

-- Davi