Hi Kristofer,
Kristofer Pettersson, 13.03.2009 15:37:
...
> 3111 Kristofer Pettersson 2009-03-13
> 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.
...
> --- a/sql/lock.cc 2009-03-04 13:31:31 +0000
> +++ b/sql/lock.cc 2009-03-13 14:37:14 +0000
> @@ -1574,30 +1574,30 @@ int set_handler_table_locks(THD *thd, TA
> {
> TABLE_LIST *tlist;
> int error= 0;
> + int trans_lock_type;
> + thr_lock_type lock_type;
...
> - lock_type= ((tlist->lock_type <= TL_READ_NO_INSERT) ?
> - HA_LOCK_IN_SHARE_MODE : HA_LOCK_IN_EXCLUSIVE_MODE);
> + trans_lock_type= ((lock_type <= TL_READ_NO_INSERT) ?
> + HA_LOCK_IN_SHARE_MODE : HA_LOCK_IN_EXCLUSIVE_MODE);
>
> if (transactional)
> {
>
>
>
> ------------------------------------------------------------------------
Hmm? When you change lock_type to trans_lock_type, shouldn't it also be
changed where it is used? Syntactically it would be correct to continue
to use lock_type, but now it has a value from thr_lock_type, but not
HA_LOCK_IN_SHARE_MODE nor HA_LOCK_IN_EXCLUSIVE_MODE. I hope, the test
suite told you this already. ;-) [if not, we may need more tests.]
Regards
Ingo
--
Ingo Strüwing, Database Group
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer
Vorsitzender des Aufsichtsrates: Martin Häring HRB München 161028
