diff options
author | unknown <svoj@mysql.com/june.mysql.com> | 2007-06-01 13:50:13 +0500 |
---|---|---|
committer | unknown <svoj@mysql.com/june.mysql.com> | 2007-06-01 13:50:13 +0500 |
commit | 93b101243d4c3155dc0f8a15dadcaef20a169345 (patch) | |
tree | d5fc3e7b9c55f53cb581b0040ec8441f18ffb8d1 /mysys/my_seek.c | |
parent | e5b2adeac1af976323f61700dd00694b9063e17f (diff) | |
download | mariadb-git-93b101243d4c3155dc0f8a15dadcaef20a169345.tar.gz |
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.
Diffstat (limited to 'mysys/my_seek.c')
0 files changed, 0 insertions, 0 deletions