Commit graph

4 commits

Author SHA1 Message Date
Sergey Vojtovich
282497dd6d MDEV-6720 - enable connection log in mysqltest by default 2016-03-31 10:11:16 +04:00
Sven Sandberg
1bd213aec3 Merged BUG#49978 from 5.1-bugteam to 5.5-bugteam. 2010-12-19 18:15:12 +01: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
Jon Olav Hauglid
47edc4cade Bug #50124 Rpl failure on DROP table with concurrent txn/non-txn
DML flow and SAVEPOINT

The problem was that replication could break if a transaction involving
both transactional and non-transactional tables was rolled back to a
savepoint. It broke if a concurrent connection tried to drop a
transactional table which was locked after the savepoint was set.
This DROP TABLE completed when ROLLBACK TO SAVEPOINT was executed as the
lock on the table was dropped by the transaction. When the slave later
tried to apply the binlog, it would fail as the table would already
have been dropped.

The reason for the problem is that transactions involving both
transactional and non-transactional tables are written fully to the
binlog during ROLLBACK TO SAVEPOINT. At the same time, metadata locks
acquired after a savepoint, were released during ROLLBACK TO SAVEPOINT.
This allowed a second connection to drop a table only used between
SAVEPOINT and ROLLBACK TO SAVEPOINT. Which caused the transaction binlog
to refer to a non-existing table when it was written during ROLLBACK
TO SAVEPOINT.

This patch fixes the problem by not releasing metadata locks when
ROLLBACK TO SAVEPOINT is executed if binlogging is enabled.
2010-06-25 09:32:24 +02:00