mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-01-18 13:02:28 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
172400 commits 2784 branches 343 tags 1.6 GiB
Commit graph

18 commits

Author SHA1 Message Date
Sergei Golubchik
d9c01e4b4a 5.5 merge 2015-01-21 12:03:02 +01:00
Praveenkumar Hulakund
43d880b7e9 Bug#19070633 - POSSIBLE ACCESS TO FREED MEMORY IN IS_FREE_LOCK() 
AND IS_USED_LOCK().

Analysis:
-----------
In functions Item_func_is_free_lock::val_int() and 
Item_func_is_used_lock::val_int(), for the specified user lock
name, pointer to its "User_level_lock" object is obtained from hash
"hash_user_locks". Mutex "LOCK_user_locks" is acquired for this
and released immediately. And we are accessing members of
User_level_lock after releasing the mutex. If same user lock is
deleted(released) from concurrent thread then accessing members
results in invalid(freed) memory access issue.

Deleting of user lock is also protected from the mutex
"LOCK_user_locks". Since this mutex is released in "val_int" 
functions mentioned above, delete operation proceeds while concurrent
thread tries to access its members.

With the test case, valgrind reports invalid read issues in val_int
functions.

Fix:
-----------
To fix this issue, in "val_int" function of classes
"Item_func_is_free_lock" and "Item_func_is_used_lock", now releasing
mutex "LOCK_user_locks" after accessing User_level_lock members.
 2014-09-16 11:28:46 +05:30
Sergei Golubchik
8867a499f7 MDEV-6050 MySQL Bug#13036505 62540: TABLE LOCKS WITHIN STORED FUNCTIONS ARE BACK IN 5.5 WITH MIXED AND ROW BI 
cherry-pick revno 4053
committer: Gopal Shankar <gopal.shankar@oracle.com>
branch nick: sf_mysql-5.6
timestamp: Fri 2012-07-20 12:25:34 +0530
message:
  Bug#13036505 62540: TABLE LOCKS WITHIN STORED FUNCTIONS ARE BACK IN
                      5.5 WITH MIXED AND ROW BI.
 2014-07-31 12:03:20 +02:00
Jon Olav Hauglid
c1b2d72900 Bug #57130 crash in Item_field::print during SHOW CREATE TABLE or VIEW 
This crash could happen if SHOW CREATE VIEW indirectly failed to open a
view due to failures to open underlying tables (or functions). Several
such errors were hidden and converted to ER_VIEW_INVALID warnings to
prevent exposing details of underlying tables for which the user have
no privileges.

However, with the changes introduced by the patch for Bug#52044,
failing to open a view will cause opened tables, views and functions
to be closed. Since the errors causing these failures were converted
to warnings, SHOW CREATE VIEW would try to continue. This made it
possible to try to access memory that had been freed, causing a crash.

This patch fixes the problem by not closing opened tables, views and
functions in these cases. This allows SHOW CREATE VIEW to continue
and also prevents it from accessing freed memory.

Test case added to lock_sync.test.
 2010-11-03 16:47:32 +01:00
Jon Olav Hauglid
b5be2fbc8d Bug #55930 Assertion `thd->transaction.stmt.is_empty() || 
thd->in_sub_stmt || (thd->state..

OPTIMIZE TABLE is not directly supported by InnoDB. Instead,
recreate and analyze of the table is done. After recreate,
the table is closed and locks are released before the table
is reopened and locks re-acquired for the analyze phase.

This assertion was triggered if OPTIMIZE TABLE failed to
acquire thr_lock locks before starting the analyze phase.
The assertion tests (among other things) that there no
active statement transaction. However, as part of acquiring
the thr_lock lock, external_lock() is called for InnoDB
tables and this causes a statement transaction to be started.
If thr_multi_lock() later fails (e.g. due to timeout),
the failure handling code causes this assert to be triggered.

This patch fixes the problem by doing rollback of the
current statement transaction in case open_ltable (used by
OPTIMIZE TABLE) fails to acquire thr_lock locks.

Test case added to lock_sync.test.
 2010-10-13 16:15:28 +02:00
Dmitry Lenev
8d0dc9b58b Part of fix for bug#52044 "FLUSH TABLES WITH READ LOCK and 
FLUSH TABLES <list> WITH READ LOCK are incompatible" to
be pushed as separate patch.

Replaced thread state name "Waiting for table", which was
used by threads waiting for a metadata lock or table flush, 
with a set of names which better reflect types of resources
being waited for.

Also replaced "Table lock" thread state name, which was used 
by threads waiting on thr_lock.c table level lock, with more
elaborate "Waiting for table level lock", to make it 
more consistent with other thread state names.

Updated test cases and their results according to these 
changes.

Fixed sys_vars.query_cache_wlock_invalidate_func test to not
to wait for timeout of wait_condition.inc script.

mysql-test/r/query_cache.result:
  Added test coverage for query_cache_wlock_invalidate
  behavior for implicitly locked tables.
mysql-test/suite/sys_vars/r/query_cache_wlock_invalidate_func.result:
  Fixed sys_vars.query_cache_wlock_invalidate_func test to not
  to wait for timeout of wait_condition.inc script. Reverted
  changes to test which introduced timeout and replaced waiting
  condition with a more appropriate one.
  Test coverage for query_cache_wlock_invalidate behavior for
  implicitly locked tables was added to query_cache.test.
mysql-test/suite/sys_vars/t/query_cache_wlock_invalidate_func.test:
  Fixed sys_vars.query_cache_wlock_invalidate_func test to not
  to wait for timeout of wait_condition.inc script. Reverted
  changes to test which introduced timeout and replaced waiting
  condition with a more appropriate one.
  Test coverage for query_cache_wlock_invalidate behavior for
  implicitly locked tables was added to query_cache.test.
mysql-test/t/query_cache.test:
  Added test coverage for query_cache_wlock_invalidate
  behavior for implicitly locked tables.
mysys/thr_lock.c:
  Replaced "Table lock" thread state name, which was used by 
  threads waiting on thr_lock.c table level lock, with more
  elaborate "Waiting for table level lock", to make it 
  consistent with thread state names which are used while
  waiting for metadata locks and table flush.
sql/mdl.cc:
  Replaced thread state name "Waiting for table", which was
  used by threads waiting for a metadata lock or table flush, 
  with a set of names which better reflect types of resources
  being waited for. 
  
  To implement this:
  - Adjusted MDL_wait::timed_wait() to take thread state name
    as parameter.
  - Introduced method of MDL_key class which allows to get
    thread state name to be used while waiting for resource
    corresponding to the key and changed code to use it.
    Added array translating namespaces to thread state names
    as part of this change.
sql/mdl.h:
  To implement this:
  - Adjusted MDL_wait::timed_wait() to take thread state name
    as parameter.
  - Introduced method of MDL_key class which allows to get
    thread state name to be used while waiting for resource
    corresponding to the key and changed code to use it.
    Added array translating namespaces to thread state names
    as part of this change.
sql/sql_base.cc:
  Replaced thread state name "Waiting for table", which was
  used by threads waiting for table flush, with a more elaborate
  "Waiting for table flush".
 2010-08-06 15:29:37 +04:00
Dmitry Lenev
7c01868287 Yet another follow-up for the 5.5 version of fix for 
bug #46947 "Embedded SELECT without FOR UPDATE is causing 
a lock".

Fixed comments in tests. Improved comments and performance of
auxiliary scripts.

mysql-test/include/check_concurrent_insert.inc:
  Changed script to use temporary table for backing up data in
  order to make this operation less expensive. Made script more
  a bit generic by allowing to use multi-column tables with it.
  Improved comments.
mysql-test/include/check_no_concurrent_insert.inc:
  Changed script to use temporary table for backing up data in
  order to make this operation less expensive. Made script more
  a bit generic by allowing to use multi-column tables with it.
  Improved comments.
mysql-test/include/check_no_row_lock.inc:
  Improved comments in auxiliary script.
mysql-test/r/innodb_mysql_lock2.result:
  Fixed errors in comments for test.
mysql-test/r/lock_sync.result:
  Fixed typo in comments for test.
mysql-test/t/innodb_mysql_lock2.test:
  Fixed errors in comments for test.
mysql-test/t/lock_sync.test:
  Fixed typo in comments for test.
 2010-05-30 13:27:44 +04:00
Jon Olav Hauglid
a03ce03977 merge from mysql-trunk-bugfixing 2010-05-05 09:25:04 +02:00
Sven Sandberg
cf5ebc5821 BUG#50670: Slave stops with error code 1644 
Clarified error messages related to unsafe statements:
 - avoid the internal technical term "row injection"
 - use 'binary log' instead of 'binlog'
 - avoid the word 'unsafeness'


mysql-test/extra/binlog_tests/blackhole.test:
  updated suppression pattern
mysql-test/extra/binlog_tests/mix_innodb_myisam_binlog.test:
  updated suppression pattern
mysql-test/extra/rpl_tests/rpl_binlog_max_cache_size.test:
  updated suppression pattern
mysql-test/extra/rpl_tests/rpl_insert_id.test:
  updated suppression pattern
mysql-test/extra/rpl_tests/rpl_loaddata.test:
  updated suppression pattern
mysql-test/extra/rpl_tests/rpl_mixing_engines.test:
  updated suppression pattern
mysql-test/extra/rpl_tests/rpl_start_stop_slave.test:
  updated suppression pattern
mysql-test/extra/rpl_tests/rpl_stm_000001.test:
  updated suppression pattern
mysql-test/extra/rpl_tests/rpl_stop_middle_group.test:
  updated suppression pattern
mysql-test/r/archive.result:
  updated result file
mysql-test/r/commit_1innodb.result:
  updated result file
mysql-test/r/ctype_cp932_binlog_stm.result:
  updated result file
mysql-test/r/partition_innodb_stmt.result:
  updated result file
mysql-test/suite/binlog/r/binlog_innodb.result:
  updated result file
mysql-test/suite/binlog/r/binlog_killed.result:
  updated result file
mysql-test/suite/binlog/r/binlog_multi_engine.result:
  updated result file
mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result:
  updated result file
mysql-test/suite/binlog/r/binlog_statement_insert_delayed.result:
  updated result file
mysql-test/suite/binlog/r/binlog_stm_blackhole.result:
  updated result file
mysql-test/suite/binlog/r/binlog_stm_do_db.result:
  updated result file
mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result:
  updated result file
mysql-test/suite/binlog/r/binlog_stm_ps.result:
  updated result file
mysql-test/suite/binlog/r/binlog_stm_row.result:
  updated result file
mysql-test/suite/binlog/r/binlog_stm_unsafe_warning.result:
  updated result file
mysql-test/suite/binlog/r/binlog_unsafe.result:
  updated result file
mysql-test/suite/binlog/t/binlog_killed.test:
  updated suppression pattern
mysql-test/suite/binlog/t/binlog_multi_engine.test:
  updated suppression pattern
mysql-test/suite/binlog/t/binlog_statement_insert_delayed.test:
  updated suppression pattern
mysql-test/suite/binlog/t/binlog_stm_ps.test:
  updated suppression pattern
mysql-test/suite/binlog/t/binlog_stm_row.test:
  updated suppression pattern
mysql-test/suite/binlog/t/binlog_stm_unsafe_warning.test:
  updated suppression pattern
mysql-test/suite/binlog/t/binlog_tmp_table.test:
  updated suppression pattern
mysql-test/suite/binlog/t/binlog_unsafe.test:
  updated suppression pattern
mysql-test/suite/ndb/r/ndb_binlog_format.result:
  updated result file
mysql-test/suite/ndb/t/ndb_binlog_format.test:
  updated suppression pattern
mysql-test/suite/perfschema/r/binlog_stmt.result:
  updated result file
mysql-test/suite/perfschema/t/binlog_stmt.test:
  updated suppression pattern
mysql-test/suite/rpl/r/rpl_begin_commit_rollback.result:
  updated result file
mysql-test/suite/rpl/r/rpl_blackhole.result:
  updated result file
mysql-test/suite/rpl/r/rpl_concurrency_error.result:
  updated result file
mysql-test/suite/rpl/r/rpl_get_lock.result:
  updated result file
mysql-test/suite/rpl/r/rpl_insert_id.result:
  updated result file
mysql-test/suite/rpl/r/rpl_insert_ignore.result:
  updated result file
mysql-test/suite/rpl/r/rpl_misc_functions.result:
  updated result file
mysql-test/suite/rpl/r/rpl_mixed_binlog_max_cache_size.result:
  updated result file
mysql-test/suite/rpl/r/rpl_mixed_mixing_engines.result:
  updated result file
mysql-test/suite/rpl/r/rpl_mysql_upgrade.result:
  updated result file
mysql-test/suite/rpl/r/rpl_non_direct_mixed_mixing_engines.result:
  updated result file
mysql-test/suite/rpl/r/rpl_non_direct_row_mixing_engines.result:
  updated result file
mysql-test/suite/rpl/r/rpl_non_direct_stm_mixing_engines.result:
  updated result file
mysql-test/suite/rpl/r/rpl_nondeterministic_functions.result:
  updated result file
mysql-test/suite/rpl/r/rpl_read_only.result:
  updated result file
mysql-test/suite/rpl/r/rpl_row_binlog_max_cache_size.result:
  updated result file
mysql-test/suite/rpl/r/rpl_row_inexist_tbl.result:
  updated result file
mysql-test/suite/rpl/r/rpl_row_mixing_engines.result:
  updated result file
mysql-test/suite/rpl/r/rpl_slow_query_log.result:
  updated result file
mysql-test/suite/rpl/r/rpl_sp.result:
  updated result file
mysql-test/suite/rpl/r/rpl_stm_000001.result:
  updated result file
mysql-test/suite/rpl/r/rpl_stm_auto_increment_bug33029.result:
  updated result file
mysql-test/suite/rpl/r/rpl_stm_binlog_max_cache_size.result:
  updated result file
mysql-test/suite/rpl/r/rpl_stm_loadfile.result:
  updated result file
mysql-test/suite/rpl/r/rpl_stm_mixing_engines.result:
  updated result file
mysql-test/suite/rpl/r/rpl_stm_start_stop_slave.result:
  updated result file
mysql-test/suite/rpl/r/rpl_stm_stop_middle_group.result:
  updated result file
mysql-test/suite/rpl/r/rpl_temp_temporary.result:
  updated result file
mysql-test/suite/rpl/r/rpl_variables_stm.result:
  updated result file
mysql-test/suite/rpl/t/rpl000013.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_begin_commit_rollback.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_blackhole.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_concurrency_error.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_err_ignoredtable.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_get_lock.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_insert.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_insert_id.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_insert_ignore.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_invoked_features.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_misc_functions.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_mixed_bit_pk.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_mysql_upgrade.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_nondeterministic_functions.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_optimize.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_read_only.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_semi_sync.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_semi_sync_event.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_session_var.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_slow_query_log.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_sp.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_stm_auto_increment_bug33029.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_stm_found_rows.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_stm_insert_delayed.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_stm_loadfile.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_temp_table.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_temp_temporary.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_temporary.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_timezone.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_trigger.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_udf.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_user_variables.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_variables_stm.test:
  updated suppression pattern
mysql-test/suite/rpl/t/rpl_view_multi.test:
  updated suppression pattern
mysql-test/suite/rpl_ndb/r/rpl_ndb_binlog_format_errors.result:
  updated result file
mysql-test/suite/rpl_ndb/t/rpl_ndb_binlog_format_errors.test:
  updated suppression pattern
mysql-test/suite/rpl_ndb/t/rpl_ndb_stm_innodb.test:
  updated suppression pattern
mysql-test/suite/sys_vars/t/rpl_init_slave_func.test:
  updated suppression pattern
mysql-test/t/archive.test:
  updated suppression pattern
mysql-test/t/commit_1innodb.test:
  updated suppression pattern
mysql-test/t/create_select_tmp.test:
  updated suppression pattern
mysql-test/t/ctype_cp932_binlog_stm.test:
  updated suppression pattern
mysql-test/t/lock_sync.test:
  updated suppression pattern
mysql-test/t/mysqlbinlog.test:
  updated suppression pattern
mysql-test/t/mysqldump.test:
  updated suppression pattern
mysql-test/t/sp_trans.test:
  updated suppression pattern
sql/log_event.cc:
  Clarified error message.
sql/share/errmsg-utf8.txt:
  Clarified error messages.
 2010-04-28 14:47:49 +02:00
Konstantin Osipov
1ab519d91f Committing on behalf or Dmitry Lenev: 
Fix for bug #46947 "Embedded SELECT without FOR UPDATE is
causing a lock", with after-review fixes.

SELECT statements with subqueries referencing InnoDB tables
were acquiring shared locks on rows in these tables when they
were executed in REPEATABLE-READ mode and with statement or
mixed mode binary logging turned on.

This was a regression which were introduced when fixing
bug 39843.

The problem was that for tables belonging to subqueries
parser set TL_READ_DEFAULT as a lock type. In cases when
statement/mixed binary logging at open_tables() time this
type of lock was converted to TL_READ_NO_INSERT lock at
open_tables() time and caused InnoDB engine to acquire
shared locks on reads from these tables. Although in some
cases such behavior was correct (e.g. for subqueries in
DELETE) in case of SELECT it has caused unnecessary locking.

This patch tries to solve this problem by rethinking our
approach to how we handle locking for SELECT and subqueries.
Now we always set TL_READ_DEFAULT lock type for all cases
when we read data. When at open_tables() time this lock
is interpreted as TL_READ_NO_INSERT or TL_READ depending
on whether this statement as a whole or call to function
which uses particular table should be written to the
binary log or not (if yes then statement should be properly
serialized with concurrent statements and stronger lock
should be acquired).

Test coverage is added for both InnoDB and MyISAM.

This patch introduces an "incompatible" change in locking
scheme for subqueries used in SELECT ... FOR UPDATE and
SELECT .. IN SHARE MODE.
In 4.1 the server would use a snapshot InnoDB read for 
subqueries in SELECT FOR UPDATE and SELECT .. IN SHARE MODE
statements, regardless of whether the binary log is on or off.
If the user required a different type of read (i.e. locking read),
he/she could request so explicitly by providing FOR UPDATE/IN SHARE MODE
clause for each individual subquery.
On of the patches for 5.0 broke this behaviour (which was not documented
or tested), and started to use locking reads fora all subqueries in SELECT ... 
FOR UPDATE/IN SHARE MODE. This patch restored 4.1 behaviour.

mysql-test/include/check_concurrent_insert.inc:
  Added auxiliary script which allows to check if statement
  reading table allows concurrent inserts in it.
mysql-test/include/check_no_concurrent_insert.inc:
  Added auxiliary script which allows to check that statement
  reading table doesn't allow concurrent inserts in it.
mysql-test/include/check_no_row_lock.inc:
  Added auxiliary script which allows to check if statement
  reading table doesn't take locks on its rows.
mysql-test/include/check_shared_row_lock.inc:
  Added auxiliary script which allows to check if statement
  reading table takes shared locks on some of its rows.
mysql-test/r/bug39022.result:
  After bug #46947 'Embedded SELECT without FOR UPDATE is
  causing a lock' was fixed test case for bug 39022 has to
  be adjusted in order to trigger execution path on which
  original problem was encountered.
mysql-test/r/innodb_mysql_lock2.result:
  Added coverage for handling of locking in various cases when
  we read data from InnoDB tables (includes test case for
  bug #46947 'Embedded SELECT without FOR UPDATE is causing a
  lock').
mysql-test/r/lock_sync.result:
  Added coverage for handling of locking in various cases when
  we read data from MyISAM tables.
mysql-test/t/bug39022.test:
  After bug #46947 'Embedded SELECT without FOR UPDATE is
  causing a lock' was fixed test case for bug 39022 has to
  be adjusted in order to trigger execution path on which
  original problem was encountered.
mysql-test/t/innodb_mysql_lock2.test:
  Added coverage for handling of locking in various cases when
  we read data from InnoDB tables (includes test case for
  bug #46947 'Embedded SELECT without FOR UPDATE is causing a
  lock').
mysql-test/t/lock_sync.test:
  Added coverage for handling of locking in various cases when
  we read data from MyISAM tables.
sql/log_event.cc:
  Since LEX::lock_option member was removed we no longer can
  rely on its value in Load_log_event::print_query() to
  determine that log event correponds to LOAD DATA CONCURRENT
  statement (this was not correct in all situations anyway).
  A new Load_log_event's member was introduced as a replacement.
  It is initialized at event object construction time and
  explicitly indicates whether LOAD DATA was concurrent.
sql/log_event.h:
  Since LEX::lock_option member was removed we no longer can
  rely on its value in Load_log_event::print_query() to
  determine that log event correponds to LOAD DATA CONCURRENT
  statement (this was not correct in all situations anyway).
  A new Load_log_event's member was introduced as a replacement.
  It is initialized at event object construction time and
  explicitly indicates whether LOAD DATA was concurrent.
sql/sp_head.cc:
  sp_head::reset_lex():
    Before parsing substatement reset part of parser state
    which needs this (e.g. set Yacc_state::m_lock_type to
    default value).
sql/sql_acl.cc:
  Since LEX::reset_n_backup_query_tables_list() now also
  resets LEX::sql_command member (as it became part of
  Query_tables_list class) we have to restore it in cases
  when while working with proxy Query_table_list we assume
  that LEX::sql_command still corresponds to original SQL
  command being executed (for example, when we are logging
  statement to the binary log while having Query_tables_list
  reset and backed up).
sql/sql_base.cc:
  Changed read_lock_type_for_table() to return a weak TL_READ
  type of lock in cases when we are executing statement which
  won't update tables directly and table doesn't belong to
  statement's prelocking list and thus can't be used by a
  stored function. It is OK to do so since in this case table
  won't be used by statement or function call which will be
  written to the binary log, so serializability requirements
  for it can be relaxed.
  One of results from this change is that SELECTs on InnoDB
  tables no longer takes shared row locks for tables which
  are used in subqueries (i.e. bug #46947 is fixed).
  Another result is that for similar SELECTs on MyISAM tables
  concurrent inserts are allowed.
  In order to implement this change signature of
  read_lock_type_for_table() function was changed to take
  pointers to Query_tables_list and TABLE_LIST objects.
sql/sql_base.h:
  - Function read_lock_type_for_table() now takes pointers
    to Query_tables_list and TABLE_LIST elements as its
    arguments since to correctly determine lock type it needs
    to know what statement is being performed and whether table
    element for which lock type to be determined belongs to
    prelocking list.
sql/sql_lex.cc:
  - Removed LEX::lock_option and st_select_lex::lock_option
    members. Places in parser that were using them now use
    Yacc_state::m_lock_type instead.
  - To emphasize that LEX::sql_command member is used during
    process of opening and locking of tables it was moved to
    Query_tables_list class. It is now reset by
    Query_tables_list::reset_query_tables_list() method.
sql/sql_lex.h:
  - Removed st_select_lex::lock_option member as there is no
    real need for per-SELECT lock type (HIGH_PRIORITY option
    should apply to the whole statement. FOR UPDATE/LOCK IN
    SHARE MODE clauses can be handled without this member).
    The main effect which was achieved by introduction of this
    member, i.e. using TL_READ_DEFAULT lock type for
    subqueries, is now achieved by setting LEX::lock_option
    (or rather its replacement - Yacc_state::m_lock_type) to
    TL_READ_DEFAULT in almost all cases.
  - To emphasize that LEX::sql_command member is used during
    process of opening and locking of tables it was moved to
    Query_tables_list class.
  - Replaced LEX::lock_option with Yacc_state::m_lock_type
    in order to emphasize that this value is relevant only
    during parsing. Unlike for LEX::lock_option the default
    value for Yacc_state::m_lock_type is TL_READ_DEFAULT.
    Note that for cases when it is OK to take a "weak" read
    lock (e.g. simple SELECT) this lock type will be converted
    to TL_READ at open_tables() time. So this change won't
    cause negative change in behavior for such statements.
    OTOH this change ensures that, for example, for SELECTs
    which are used in stored functions TL_READ_NO_INSERT lock
    is taken when necessary and as result calls to such stored
    functions can be written to the binary log with correct
    serialization.
sql/sql_load.cc:
  Load_log_event constructor now requires a parameter that
  indicates whether LOAD DATA is concurrent.
sql/sql_parse.cc:
  LEX::lock_option was replaced with Yacc_state::m_lock_type.
  And instead of resetting the latter implicitly in
  mysql_init_multi_delete() we do it explicitly in the
  places in parser which call this function.
sql/sql_priv.h:
  - To be able more easily distinguish high-priority SELECTs
    in st_select_lex::print() method added flag for
    HIGH_PRIORITY option.
sql/sql_select.cc:
  Changed code not to rely on LEX::lock_option to determine
  that it is high-priority SELECT. It was replaced with
  Yacc_state::m_lock_type which is accessible only at
  parse time. So instead of LEX::lock_option we now rely
  on a newly introduced flag for st_select_lex::options -
  SELECT_HIGH_PRIORITY.
sql/sql_show.cc:
  Since LEX::reset_n_backup_query_tables_list() now also
  resets LEX::sql_command member (as it became part of
  Query_tables_list class) we have to restore it in cases
  when while working with proxy Query_table_list we assume
  that LEX::sql_command still corresponds to original SQL
  command being executed.
sql/sql_table.cc:
  Since LEX::reset_query_tables_list() now also resets
  LEX::sql_command member (as it became part of
  Query_tables_list class) we have to restore value of this
  member when this method is called by mysql_admin_table(),
  to make this code safe for re-execution.
sql/sql_trigger.cc:
  Since LEX::reset_n_backup_query_tables_list() now also
  resets LEX::sql_command member (as it became part of
  Query_tables_list class) we have to restore it in cases
  when while working with proxy Query_table_list we assume
  that LEX::sql_command still corresponds to original SQL
  command being executed (for example, when we are logging
  statement to the binary log while having Query_tables_list
  reset and backed up).
sql/sql_update.cc:
  Function read_lock_type_for_table() now takes pointers
  to Query_tables_list and TABLE_LIST elements as its
  arguments since to correctly determine lock type it needs
  to know what statement is being performed and whether table
  element for which lock type to be determined belongs to
  prelocking list.
sql/sql_yacc.yy:
  - Removed st_select_lex::lock_option member as there is no
    real need for per-SELECT lock type (HIGH_PRIORITY option
    should apply to the whole statement. FOR UPDATE/LOCK IN
    SHARE MODE clauses can be handled without this member).
    The main effect which was achieved by introduction of this
    member, i.e. using TL_READ_DEFAULT lock type for
    subqueries, is now achieved by setting LEX::lock_option
    (or rather its replacement - Yacc_state::m_lock_type) to
    TL_READ_DEFAULT in almost all cases.
  - Replaced LEX::lock_option with Yacc_state::m_lock_type
    in order to emphasize that this value is relevant only
    during parsing. Unlike for LEX::lock_option the default
    value for Yacc_state::m_lock_type is TL_READ_DEFAULT.
    Note that for cases when it is OK to take a "weak" read
    lock (e.g. simple SELECT) this lock type will be converted
    to TL_READ at open_tables() time. So this change won't
    cause negative change in behavior for such statements.
    OTOH this change ensures that, for example, for SELECTs
    which are used in stored functions TL_READ_NO_INSERT lock
    is taken when necessary and as result calls to such stored
    functions can be written to the binary log with correct
    serialization.
  - To be able more easily distinguish high-priority SELECTs
    in st_select_lex::print() method we now use new flag
    in st_select_lex::options bit-field.
 2010-04-28 14:04:11 +04:00
Jon Olav Hauglid
4347e302a8 Bug #51391 Deadlock involving events during rqg_info_schema test 
This was a deadlock between CREATE/ALTER/DROP EVENT and a query
accessing both the mysql.event table and I_S.GLOBAL_VARIABLES.

The root of the problem was that the LOCK_event_metadata mutex was
used to both protect the "event_scheduler" global system variable
and the internal event data structures used by CREATE/ALTER/DROP EVENT.

The deadlock would occur if CREATE/ALTER/DROP EVENT held
LOCK_event_metadata while trying to open the mysql.event table,
at the same time as the query had mysql.event open, trying to
lock LOCK_event_metadata to access "event_scheduler".

This bug was fixed in the scope of Bug#51160 by using only
LOCK_global_system_variables to protect "event_scheduler".
This makes it so that the query above won't lock LOCK_event_metadata,
thereby preventing this deadlock from occuring.

This patch contains no code changes.
Test case added to lock_sync.test.
 2010-04-15 14:14:28 +02:00
Konstantin Osipov
e6cb88eb74 next-4284 tree: 
fix lock_sync.test failure in row based replication mode.
 2010-02-11 19:10:34 +03:00
Konstantin Osipov
e7b332ba83 Merge next-mr -> next-4284. 2010-02-05 01:08:08 +03:00
Jon Olav Hauglid
a19377e0d7 Bug #50821 Deadlock between LOCK TABLES and ALTER TABLE 
This was a deadlock between ALTER TABLE and another DML statement
(or LOCK TABLES ... READ). ALTER TABLE would wait trying to upgrade
its lock to MDL_EXCLUSIVE and the DML statement would wait trying
to acquire a TL_READ_NO_INSERT table level lock.

This could happen if one connection first acquired a MDL_SHARED_READ
lock on a table. In another connection ALTER TABLE is then started.
ALTER TABLE eventually blocks trying to upgrade to MDL_EXCLUSIVE,
but while holding a TL_WRITE_ALLOW_READ table level lock.

If the first connection then tries to acquire TL_READ_NO_INSERT,
it will block and we have a deadlock since neither connection can
proceed.

This patch fixes the problem by allowing TL_READ_NO_INSERT 
locks to be granted if another connection holds TL_WRITE_ALLOW_READ
on the same table. This will allow the DML statement to proceed
such that it eventually can release its MDL lock which in turn
makes ALTER TABLE able to proceed.

Note that TL_READ_NO_INSERT was already partially compatible with
TL_WRITE_ALLOW_READ as the latter would be granted if the former
lock was held. This patch just makes the opposite true as well.

Also note that since ALTER TABLE takes an upgradable MDL lock,
there will be no starvation of ALTER TABLE statements by
statements acquiring TL_READ or TL_READ_NO_INSERT.

Test case added to lock_sync.test.
 2010-02-04 10:00:36 +01:00
Dmitry Lenev
eba5d30e67 Implement new type-of-operation-aware metadata locks. 
Add a wait-for graph based deadlock detector to the
MDL subsystem.

Fixes bug #46272 "MySQL 5.4.4, new MDL: unnecessary deadlock" and
bug #37346 "innodb does not detect deadlock between update and
alter table".

The first bug manifested itself as an unwarranted abort of a
transaction with ER_LOCK_DEADLOCK error by a concurrent ALTER
statement, when this transaction tried to repeat use of a
table, which it has already used in a similar fashion before
ALTER started.

The second bug showed up as a deadlock between table-level
locks and InnoDB row locks, which was "detected" only after
innodb_lock_wait_timeout timeout.

A transaction would start using the table and modify a few
rows.
Then ALTER TABLE would come in, and start copying rows
into a temporary table. Eventually it would stumble on
the modified records and get blocked on a row lock.
The first transaction would try to do more updates, and get
blocked on thr_lock.c lock.
This situation of circular wait would only get resolved
by a timeout.

Both these bugs stemmed from inadequate solutions to the
problem of deadlocks occurring between different
locking subsystems.

In the first case we tried to avoid deadlocks between metadata
locking and table-level locking subsystems, when upgrading shared
metadata lock to exclusive one.
Transactions holding the shared lock on the table and waiting for
some table-level lock used to be aborted too aggressively.

We also allowed ALTER TABLE to start in presence of transactions
that modify the subject table. ALTER TABLE acquires
TL_WRITE_ALLOW_READ lock at start, and that block all writes
against the table (naturally, we don't want any writes to be lost
when switching the old and the new table). TL_WRITE_ALLOW_READ
lock, in turn, would block the started transaction on thr_lock.c
lock, should they do more updates. This, again, lead to the need
to abort such transactions.

The second bug occurred simply because we didn't have any
mechanism to detect deadlocks between the table-level locks
in thr_lock.c and row-level locks in InnoDB, other than
innodb_lock_wait_timeout.

This patch solves both these problems by moving lock conflicts
which are causing these deadlocks into the metadata locking
subsystem, thus making it possible to avoid or detect such
deadlocks inside MDL.

To do this we introduce new type-of-operation-aware metadata
locks, which allow MDL subsystem to know not only the fact that
transaction has used or is going to use some object but also what
kind of operation it has carried out or going to carry out on the
object.

This, along with the addition of a special kind of upgradable
metadata lock, allows ALTER TABLE to wait until all
transactions which has updated the table to go away.
This solves the second issue.
Another special type of upgradable metadata lock is acquired
by LOCK TABLE WRITE. This second lock type allows to solve the
first issue, since abortion of table-level locks in event of
DDL under LOCK TABLES becomes also unnecessary.

Below follows the list of incompatible changes introduced by
this patch:

- From now on, ALTER TABLE and CREATE/DROP TRIGGER SQL (i.e. those
  statements that acquire TL_WRITE_ALLOW_READ lock)
  wait for all transactions which has *updated* the table to
  complete.

- From now on, LOCK TABLES ... WRITE, REPAIR/OPTIMIZE TABLE
  (i.e. all statements which acquire TL_WRITE table-level lock) wait
  for all transaction which *updated or read* from the table
  to complete.
  As a consequence, innodb_table_locks=0 option no longer applies
  to LOCK TABLES ... WRITE.

- DROP DATABASE, DROP TABLE, RENAME TABLE no longer abort
  statements or transactions which use tables being dropped or
  renamed, and instead wait for these transactions to complete.

- Since LOCK TABLES WRITE now takes a special metadata lock,
  not compatible with with reads or writes against the subject table
  and transaction-wide, thr_lock.c deadlock avoidance algorithm
  that used to ensure absence of deadlocks between LOCK TABLES
  WRITE and other statements is no longer sufficient, even for
  MyISAM. The wait-for graph based deadlock detector of MDL
  subsystem may sometimes be necessary and is involved. This may
  lead to ER_LOCK_DEADLOCK error produced for multi-statement
  transactions even if these only use MyISAM:

  session 1:         session 2:
  begin;

  update t1 ...      lock table t2 write, t1 write;
                     -- gets a lock on t2, blocks on t1

  update t2 ...
  (ER_LOCK_DEADLOCK)

- Finally,  support of LOW_PRIORITY option for LOCK TABLES ... WRITE
  was abandoned.
  LOCK TABLE ... LOW_PRIORITY WRITE from now on has the same
  priority as the usual LOCK TABLE ... WRITE.
  SELECT HIGH PRIORITY no longer trumps LOCK TABLE ... WRITE  in
  the wait queue.

- We do not take upgradable metadata locks on implicitly
  locked tables. So if one has, say, a view v1 that uses
  table t1, and issues:
  LOCK TABLE v1 WRITE;
  FLUSH TABLE t1; -- (or just 'FLUSH TABLES'),
  an error is produced.
  In order to be able to perform DDL on a table under LOCK TABLES,
  the table must be locked explicitly in the LOCK TABLES list.

mysql-test/include/handler.inc:
  Adjusted test case to trigger an execution path on which bug 41110
  "crash with handler command when used concurrently with alter
  table" and bug 41112 "crash in mysql_ha_close_table/get_lock_data
  with alter table" were originally discovered. Left old test case
  which no longer triggers this execution path for the sake of
  coverage.
  Added test coverage for HANDLER SQL statements and type-aware
  metadata locks.
  Added a test for the global shared lock and HANDLER SQL.
  Updated tests to take into account that the old simple deadlock
  detection heuristics was replaced with a graph-based deadlock
  detector.
mysql-test/r/debug_sync.result:
  Updated results (see debug_sync.test).
mysql-test/r/handler_innodb.result:
  Updated results (see handler.inc test).
mysql-test/r/handler_myisam.result:
  Updated results (see handler.inc test).
mysql-test/r/innodb-lock.result:
  Updated results (see innodb-lock.test).
mysql-test/r/innodb_mysql_lock.result:
  Updated results (see innodb_mysql_lock.test).
mysql-test/r/lock.result:
  Updated results (see lock.test).
mysql-test/r/lock_multi.result:
  Updated results (see lock_multi.test).
mysql-test/r/lock_sync.result:
  Updated results (see lock_sync.test).
mysql-test/r/mdl_sync.result:
  Updated results (see mdl_sync.test).
mysql-test/r/sp-threads.result:
  SHOW PROCESSLIST output has changed due to the fact that waiting
  for LOCK TABLES WRITE now happens within metadata locking
  subsystem.
mysql-test/r/truncate_coverage.result:
  Updated results (see truncate_coverage.test).
mysql-test/suite/funcs_1/datadict/processlist_val.inc:
  SELECT FROM I_S.PROCESSLIST output has changed due to fact that
  waiting for LOCK TABLES WRITE now happens within metadata locking
  subsystem.
mysql-test/suite/funcs_1/r/processlist_val_no_prot.result:
  SELECT FROM I_S.PROCESSLIST output has changed due to fact that
  waiting for LOCK TABLES WRITE now happens within metadata locking
  subsystem.
mysql-test/suite/rpl/t/rpl_sp.test:
  Updated to a new SHOW PROCESSLIST state name.
mysql-test/t/debug_sync.test:
  Use LOCK TABLES READ instead of LOCK TABLES WRITE as the latter
  no longer allows to trigger execution path involving waiting on
  thr_lock.c lock and therefore reaching debug sync-point covered
  by this test.
mysql-test/t/innodb-lock.test:
  Adjusted test case to the fact that innodb_table_locks=0 option is
  no longer supported, since LOCK TABLES WRITE handles all its
  conflicts within MDL subsystem.
mysql-test/t/innodb_mysql_lock.test:
  Added test for bug #37346 "innodb does not detect deadlock between
  update and alter table".
mysql-test/t/lock.test:
  Added test coverage which checks the fact that we no longer support
  DDL under LOCK TABLES on tables which were locked implicitly.
  Adjusted existing test cases accordingly.
mysql-test/t/lock_multi.test:
  Added test for bug #46272 "MySQL 5.4.4, new MDL: unnecessary
  deadlock".  Adjusted other test cases to take into account the
  fact that waiting for LOCK TABLES ... WRITE now happens within MDL
  subsystem.
mysql-test/t/lock_sync.test:
  Since LOCK TABLES ... WRITE now takes SNRW metadata lock for
  tables locked explicitly we have to implicitly lock InnoDB tables
  (through view) to trigger the table-level lock conflict between
  TL_WRITE and TL_WRITE_ALLOW_WRITE.
mysql-test/t/mdl_sync.test:
  Added basic test coverage for type-of-operation-aware metadata
  locks. Also covered with tests some use cases involving HANDLER
  statements in which a deadlock could arise.
  Adjusted existing tests to take type-of-operation-aware MDL into
  account.
mysql-test/t/multi_update.test:
  Update to a new SHOW PROCESSLIST state name.
mysql-test/t/truncate_coverage.test:
  Adjusted test case after making LOCK TABLES WRITE to wait until
  transactions that use the table to be locked are completed.
  Updated to the changed name of DEBUG_SYNC point.
sql/handler.cc:
  Global read lock functionality has been
  moved into a class.
sql/lock.cc:
  Global read lock functionality has been
  moved into a class.
  Updated code to use the new MDL API.
sql/mdl.cc:
  Introduced new type-of-operation aware metadata locks.
  To do this:
  - Changed MDL_lock to use one list for waiting requests and one
    list for granted requests. For each list, added a bitmap
    that holds information what lock types a list contains.
    Added a helper class MDL_lock::List to manipulate with granted
    and waited lists while keeping the bitmaps in sync
    with list contents.
  - Changed lock-compatibility functions to use bitmaps that
    define compatibility.
  - Introduced a graph based deadlock detector inspired by
    waiting_threads.c from Maria implementation.
  - Now that we have a deadlock detector, and no longer have
    a global lock to protect individual lock objects, but rather
    use an rw lock per object, removed redundant code for upgrade,
    and the global read lock. Changed the MDL API to
    no longer require the caller to acquire the global
    intention exclusive lock by means of a separate method.
    Removed a few more methods that became redundant.
  - Removed deadlock detection heuristic, it has been made
    obsolete by the deadlock detector.
  - With operation-type-aware metadata locks, MDL subsystem has
    become aware of potential conflicts between DDL and open
    transactions. This made it possible to remove calls to
    mysql_abort_transactions_with_shared_lock() from acquisition
    paths for exclusive lock and lock upgrade. Now we can simply
    wait for these transactions to complete without fear of
    deadlock. Function mysql_lock_abort() has also become
    unnecessary for all conflicting cases except when a DDL
    conflicts with a connection that has an open HANDLER.
sql/mdl.h:
  Introduced new type-of-operation aware metadata locks.
  Introduced a graph based deadlock detector and supporting
  methods.
  Added comments.
  God rid of redundant API calls.
  Renamed m_lt_or_ha_sentinel to m_trans_sentinel,
  since now it guards the global read lock as well as
  LOCK TABLES and HANDLER locks.
sql/mysql_priv.h:
  Moved the global read lock functionality into a
  class.
  Added MYSQL_OPEN_FORCE_SHARED_MDL flag which forces
  open_tables() to take MDL_SHARED on tables instead of
  metadata locks specified in the parser. We use this to
  allow PREPARE run concurrently in presence of
  LOCK TABLES ... WRITE.
  Added signature for find_table_for_mdl_ugprade().
sql/set_var.cc:
  Global read lock functionality has been
  moved into a class.
sql/sp_head.cc:
  When creating TABLE_LIST elements for prelocking or
  system tables set the type of request for metadata
  lock according to the operation that will be performed
  on the table.
sql/sql_base.cc:
  - Updated code to use the new MDL API.
  - In order to avoid locks starvation we take upgradable
    locks all at once. As result implicitly locked tables no
    longer get an upgradable lock. Consequently DDL and FLUSH
    TABLES for such tables is prohibited.
    find_write_locked_table() was replaced by
    find_table_for_mdl_upgrade() function.
    open_table() was adjusted to return TABLE instance with
    upgradable ticket when necessary.
  - We no longer wait for all locks on OT_WAIT back off
    action -- only on the lock that caused the wait
    conflict. Moreover, now we distinguish cases when we
    have to wait due to conflict in MDL and old version
    of table in TDC.
  - Upate mysql_notify_threads_having_share_locks()
    to only abort thr_lock.c waits of threads that
    have open HANDLERs, since lock conflicts with only
    these threads now can lead to deadlocks not detectable
    by the MDL deadlock detector.
  - Remove mysql_abort_transactions_with_shared_locks()
    which is no longer needed.
sql/sql_class.cc:
  Global read lock functionality has been moved into a class.
  Re-arranged code in THD::cleanup() to simplify assert.
sql/sql_class.h:
  Introduced class to incapsulate global read lock
  functionality.
  Now sentinel in MDL subsystem guards the global read lock
  as well as LOCK TABLES and HANDLER locks. Adjusted code
  accordingly.
sql/sql_db.cc:
  Global read lock functionality has been moved into a class.
sql/sql_delete.cc:
  We no longer acquire upgradable metadata locks on tables
  which are locked by LOCK TABLES implicitly. As result
  TRUNCATE TABLE is no longer allowed for such tables.
  Updated code to use the new MDL API.
sql/sql_handler.cc:
  Inform MDL_context about presence of open HANDLERs.
  Since HANLDERs break MDL protocol by acquiring table-level
  lock while holding only S metadata lock on a table MDL
  subsystem should take special care about such contexts (Now
  this is the only case when mysql_lock_abort() is used).
sql/sql_parse.cc:
  Global read lock functionality has been moved into a class.
  Do not take upgradable metadata locks when opening tables
  for CREATE TABLE SELECT as it is not necessary and limits
  concurrency.
  When initializing TABLE_LIST objects before adding them
  to the table list set the type of request for metadata lock
  according to the operation that will be performed on the
  table.
  We no longer acquire upgradable metadata locks on tables
  which are locked by LOCK TABLES implicitly. As result FLUSH
  TABLES is no longer allowed for such tables.
sql/sql_prepare.cc:
  Use MYSQL_OPEN_FORCE_SHARED_MDL flag when opening
  tables during PREPARE. This allows PREPARE to run
  concurrently in presence of LOCK TABLES ... WRITE.
sql/sql_rename.cc:
  Global read lock functionality has been moved into a class.
sql/sql_show.cc:
  Updated code to use the new MDL API.
sql/sql_table.cc:
  Global read lock functionality has been moved into a class.
  We no longer acquire upgradable metadata locks on tables
  which are locked by LOCK TABLES implicitly. As result DROP
  TABLE is no longer allowed for such tables.
  Updated code to use the new MDL API.
sql/sql_trigger.cc:
  Global read lock functionality has been moved into a class.
  We no longer acquire upgradable metadata locks on tables
  which are locked by LOCK TABLES implicitly. As result
  CREATE/DROP TRIGGER is no longer allowed for such tables.
  Updated code to use the new MDL API.
sql/sql_view.cc:
  Global read lock functionality has been moved into a class.
  Fixed results of wrong merge that led to misuse of GLR API.
  CREATE VIEW statement is not a commit statement.
sql/table.cc:
  When resetting TABLE_LIST objects for PS or SP re-execution
  set the type of request for metadata lock according to the
  operation that will be performed on the table. Do the same
  in auxiliary function initializing metadata lock requests
  in a table list.
sql/table.h:
  When initializing TABLE_LIST objects set the type of request
  for metadata lock according to the operation that will be
  performed on the table.
sql/transaction.cc:
  Global read lock functionality has been moved into a class.
 2010-02-01 14:43:06 +03:00
Konstantin Osipov
cd155be564 Backport of: 
------------------------------------------------------------
revno: 3035.4.1
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: 39897-6.0
timestamp: Thu 2009-01-15 12:17:57 -0200
message:
Bug#39897: lock_multi fails in pushbuild: timeout waiting for processlist

The problem is that relying on the "Table lock" thread state in
its current position to detect that a thread is waiting on a lock
is race prone. The "Table lock" state change happens before the
thread actually tries to grab a lock on a table.

The solution is to move the "Table lock" state so that its set
only when a thread is actually going to wait for a lock. The state
change happens after the thread fails to grab the lock (because it
is owned by other thread) and proceeds to wait on a condition.

This is considered part of work related to WL#4284 "Transactional
DDL locking"
Warning: this patch contains an incompatible change. 
When waiting on a lock in thr_lock.c, the server used to display "Locked"
processlist state. After this patch, the state is "Table lock".
The new state was actually intended to be display since year 2002,
when Monty added it. But up until removal of thd->locked boolean
member, this state was ignored by SHOW PROCESSLIST code.  

mysql-test/r/lock_multi.result:
  A style fix.
mysql-test/r/sp-threads.result:
  Changed output of SHOW PROCESSLIST (new wait state).
mysql-test/t/lock_multi.test:
  Use a more accurate state description when waiting inside thr_lock.c.
mysql-test/t/lock_sync.test:
  Use a more accurate state description when waiting inside thr_lock.c.
mysql-test/t/multi_update.test:
  Use a more accurate state description when waiting inside thr_lock.c.
mysql-test/t/query_cache_28249.test:
  Use a more accurate state description when waiting inside thr_lock.c.
mysql-test/t/sp_notembedded.test:
  Use a more accurate state description when waiting inside thr_lock.c.
mysql-test/t/status.test:
  Use a more accurate state description when waiting inside thr_lock.c.
mysys/thr_lock.c:
  Update thread state while waiting for a table lock.
sql/lock.cc:
  State change was moved inside thr_lock.c.
 2009-12-03 23:08:27 +03:00
Dmitry Lenev
1e5804f2c5 Fixed lock_sync.test failure in mysql-next-mr tree in embedded mode. 
Disabled execution of this test for embedded server until fix for
bug 41971 'Thread state on embedded server is always "Writing to net"'
is back-ported to this tree.
 2009-10-27 12:43:40 +03:00
Dmitry Lenev
86c23fa708 Fix for bug #45143 "All connections hang on concurrent ALTER TABLE". 
Concurrent execution of statements which require non-table-level
write locks on several instances of the same table (such as
SELECT ... FOR UPDATE which uses same InnoDB table twice or a DML
statement which invokes trigger which tries to update same InnoDB
table directly and through stored function) and statements which
required table-level locks on this table (e.g. LOCK TABLE ... WRITE,
ALTER TABLE, ...) might have resulted in a deadlock.

The problem occured when a thread tried to acquire write lock
(TL_WRITE_ALLOW_WRITE) on the table but had to wait since there was
a pending write lock (TL_WRITE, TL_WRITE_ALLOW_READ) on this table
and we failed to detect that this thread already had another instance
of write lock on it (so in fact we were trying to acquire recursive
lock) because there was also another thread holding write lock on the
table (also TL_WRITE_ALLOW_WRITE). When the latter thread released
its lock neither the first thread nor the thread trying to acquire
TL_WRITE/TL_WRITE_ALLOW_READ were woken up (as table was still write
locked by the first thread) so we ended up with a deadlock.

This patch solves this problem by ensuring that thread which
already has write lock on the table won't wait when it tries
to acquire second write lock on the same table.

mysql-test/r/lock_sync.result:
  Added test case for bug #45143 "All connections hang on concurrent
  ALTER TABLE".
mysql-test/t/lock_sync.test:
  Added test case for bug #45143 "All connections hang on concurrent
  ALTER TABLE".
mysys/thr_lock.c:
  Ensured that thread can acquire write lock on the table without
  waiting if it already has write lock on it even if there are other
  threads holding write locks on this table (this is normal situation
  for, e.g., TL_WRITE_ALLOW_WRITE type of lock).
  
  Adjusted comments to better explain why it is OK to do so and added
  asserts to prevent introduction of scenarios in which this can cause
  problems.
 2009-10-26 22:38:03 +03:00