Hi Kristofer,
On 3/12/09 8:43 AM, Kristofer Pettersson wrote:
> #At file:///home/thek/Development/cpp/mysqlbzr/mysql-6.0-bugteam/ based on
> revid:kristofer.pettersson@stripped
>
> 3109 Kristofer Pettersson 2009-03-12
> Bug#43568 set_handler_table_locks uses parser tokens instead of correct
> lock_options
>
> set_handler_table_locks uses parser tokens instead of correct lock options to
> determine the correct lock to set.
>
> After open_tables, the correct lock option is stored in
> TABLE::reginfo.lock_type.
> Failing to use the correct lock option might create issues with binlog and
> replication.
>
> modified:
> sql/lock.cc
> === modified file 'sql/lock.cc'
> --- a/sql/lock.cc 2009-02-16 21:18:45 +0000
> +++ b/sql/lock.cc 2009-03-12 11:43:21 +0000
> @@ -1585,18 +1585,11 @@ int set_handler_table_locks(THD *thd, TA
> if (tlist->placeholder())
> continue;
>
> - DBUG_ASSERT((tlist->lock_type == TL_READ) ||
> - (tlist->lock_type == TL_READ_NO_INSERT) ||
> - (tlist->lock_type == TL_WRITE_DEFAULT) ||
> - (tlist->lock_type == TL_WRITE) ||
> - (tlist->lock_type == TL_WRITE_CONCURRENT_INSERT) ||
> - (tlist->lock_type == TL_WRITE_LOW_PRIORITY));
> -
Please add a assert like this:
DBUG_ASSERT(lock_type != TL_WRITE_DEFAULT && lock_type != TL_READ_DEFAULT);
with lock_type taken from reginfo.
> /*
> Every tlist object has a proper lock_type set. Even if it came in
> the list as a base table from a view only.
> */
> - lock_type= ((tlist->lock_type<= TL_READ_NO_INSERT) ?
> + lock_type= ((tlist->table->reginfo.lock_type<= TL_READ_NO_INSERT) ?
> HA_LOCK_IN_SHARE_MODE : HA_LOCK_IN_EXCLUSIVE_MODE);
>
> if (transactional)
>
Please add a warning to definition of thr_lock_type that if a new lock
type is added, one should evaluate the impact on transactional locks.
Regards,
-- Davi Arnaut
