mirror of
https://github.com/MariaDB/server.git
synced 2025-07-29 05:21:33 +03:00
Fix for bug #25044 "ALTER TABLE ... ENABLE KEYS acquires global 'opening
tables' lock." Execution of ALTER TABLE ... ENABLE KEYS on a table (which can take rather long time) prevented concurrent execution of all statements using tables. The problem was caused by the fact that we were holding LOCK_open mutex during whole duration of this statement and particularly during call to handler::enable_indexes(). This behavior was introduced as part of the fix for bug 14262 "SP: DROP PROCEDURE|VIEW (maybe more) write to binlog too late (race cond)" The patch simply restores old behavior. Note that we can safely do this as this operation takes exclusive lock (similar to name-lock) which blocks both DML and DDL on the table being altered. It also introduces mysql-test/include/wait_show_pattern.inc helper script which is used to make test-case for this bug robust enough.
This commit is contained in:
@ -104,50 +104,21 @@
|
||||
eval SELECT "let \$result_pattern= $result_pattern ;" AS "";
|
||||
SELECT '--source include/wait_slave_status.inc' AS "";
|
||||
|
||||
# We accept to wait maximum 30 seconds (0.2 sec/loop).
|
||||
let $max_wait= 150;
|
||||
while ($max_wait)
|
||||
{
|
||||
let $my_val= `SHOW SLAVE STATUS`;
|
||||
# Now we have the first record of the SHOW result set as one fat string
|
||||
# within the variable $my_val.
|
||||
|
||||
eval SET @my_val = '$my_val';
|
||||
# DEBUG eval SELECT @my_val AS "response to SHOW SLAVE STATUS";
|
||||
|
||||
eval SELECT @my_val LIKE $result_pattern INTO @success;
|
||||
# @success is '1' if we have a match
|
||||
# '0' if we have no match
|
||||
# DEBUG SELECT @success;
|
||||
|
||||
let $success= `SELECT @success`;
|
||||
let $no_success= `SELECT @success = 0`;
|
||||
if ($success)
|
||||
{
|
||||
# We reached the expected result and want to jump out of the loop
|
||||
# without unneeded sleeps.
|
||||
# Attention: Do not set $max_wait to 0, because "while" with negative value
|
||||
# does not work.
|
||||
let $max_wait= 1;
|
||||
}
|
||||
if ($no_success)
|
||||
{
|
||||
# We did not reach the expected result and will have to sleep again
|
||||
# or jump out of the loop, when max_wait is exhausted.
|
||||
real_sleep 0.2;
|
||||
}
|
||||
dec $max_wait;
|
||||
}
|
||||
let $show_type= SLAVE STATUS;
|
||||
let $show_pattern= $result_pattern;
|
||||
--enable_query_log
|
||||
if ($no_success)
|
||||
|
||||
--source include/wait_show_pattern.inc
|
||||
|
||||
if (!$success)
|
||||
{
|
||||
let $message= ! Attention: Timeout in wait_slave_status.inc.
|
||||
| Possible reasons with decreasing probability:
|
||||
| - The LIKE pattern ($result_pattern) is wrong, because the
|
||||
| - The LIKE pattern is wrong, because the
|
||||
| testcase was altered or the layout of the
|
||||
| SHOW SLAVE STATUS result set changed.
|
||||
| - There is a new bug within the replication.
|
||||
| - We met an extreme testing environment and $max_wait is
|
||||
| - We met an extreme testing environment and timeout is
|
||||
| too small.;
|
||||
--source include/show_msg80.inc
|
||||
--echo DEBUG INFO START (wait_slave_status.inc):
|
||||
|
Reference in New Issue
Block a user