From 93b101243d4c3155dc0f8a15dadcaef20a169345 Mon Sep 17 00:00:00 2001 From: unknown Date: Fri, 1 Jun 2007 13:50:13 +0500 Subject: BUG#28574 - repair table causes queries to fail with various corruption errors: 126,134,145 When one thread attempts to lock two (or more) tables and another thread executes statement that aborts these locks (e.g. REPAIR TABLE) we may get a table object with wrong lock type in a table cache. For example if SELECT FROM t1,t2 was aborted, subsequent INSERT INTO t1 may be executed under read lock. As a result we may get various table corruptions and even a server crash. This is fixed by resetting lock type in case lock was aborted by another thread. I failed to create reasonable test case for this bug. sql/lock.cc: If thr_multi_lock was aborted by another thread, it unlocks tables that were locked before one that was aborted. Lock type for tables that were after a table that was aborted preserved. Thus we need to reset lock data in case thr_multi_lock was aborted. --- sql/lock.cc | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'sql/lock.cc') diff --git a/sql/lock.cc b/sql/lock.cc index 3b2b2857f65..92c34f84b97 100644 --- a/sql/lock.cc +++ b/sql/lock.cc @@ -155,6 +155,13 @@ MYSQL_LOCK *mysql_lock_tables(THD *thd, TABLE **tables, uint count, uint flags) if (thr_multi_lock(sql_lock->locks + sql_lock->lock_count, sql_lock->lock_count)) { + /* + reset_lock_data is required here. If thr_multi_lock fails it + resets lock type for tables, which were locked before (and + including) one that caused error. Lock type for other tables + preserved. + */ + reset_lock_data(sql_lock); thd->some_tables_deleted=1; // Try again sql_lock->lock_count=0; // Locks are alread freed } -- cgit v1.2.1