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.

1 files changed, 7 insertions, 0 deletions

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
     }