Re: bk commit into 5.1 tree (dlenev:1.2575) BUG#21281

[Konstantin Osipov]

* dlenev@stripped <dlenev@stripped> [07/08/02 10:13]:

OK to push.

> ChangeSet@stripped, 2007-08-02 09:56:00+04:00, dlenev@stripped +3 -0
>   Proposed fix for bug #21281 "Pending write lock is incorrectly removed
>   when its statement being KILLed".
>   
>   When statement which was trying to obtain write lock on then table and
>   which was blocked by existing read lock was killed, concurrent statements
>   that were trying to obtain read locks on the same table and that were
>   blocked by the presence of this pending write lock were not woken up and
>   had to wait until this first read lock goes away.
>   
>   This problem was caused by the fact that we forgot to wake up threads
>   which pending requests could have been satisfied after removing lock
>   request for the killed thread.
>   
>   The patch solves the problem by waking up those threads in such situation. 
>   
>   Questions for reviewers are marked by QQ.
>   
>   QQ: Should we fix this bug in 5.0 ?

Yes.

> +
> +  QQ: May be there is a better name for this procedure?
> +      Should this function be 'inline'?

thr_reschedule_locks?

No, it shouldn't be inline, the compiler will inline it
automatically if needed.

> +static void wake_up_waiters(THR_LOCK *lock)
> +{
> +  THR_LOCK_DATA *data;
> +  enum thr_lock_type lock_type;
> +

-- 
-- Konstantin Osipov              Software Developer, Moscow, Russia
-- MySQL AB, www.mysql.com   The best DATABASE COMPANY in the GALAXY