- rewrite "check warnings" to be faster by not creating a full join
between error_log and suspicious_patterns while running REGEXP.
Instead add a column to error_log that will be set to 1 to indicate
a warning and run the 6 REGEXP's we have for suspicious lines as
6 separate full table scans.
- Remove the "suspicious_patterns" table from mtr db
- Use 'xykls37' as separator when loading the error log, that line should
hopefully never exist in a line that should be a warning
- Clear test variables "comment" and "logfile" to make sure thay aren't
already set from previous run of same test
- Print warning if test result already set and set it anyway
The original goal of the test, as reported on BUG #25721, is to check whether
a deadlock happens or not when concurrently CREATING/ALTERING/DROPPING the
same server. For that a procedure (p1) is created that runs the exact same
CREATE/ALTER/DROP statements for 10K iterations and two different connections
(threads - t1 and t2) call p1 concurrently. At the end of the 10K iterations,
the test checks if there was errors while running the loop (SELECT e >0).
The problem is that In some cases it may happen that one thread, t1, gets
scheduled to execute with just enough time to complete the iteration and
never bumps into the other thread t2. Meaning that t1 will never run into an
SQL exception. On the other hand, the other thread, t2, may run into t1 and
never issue any/part of its own statements because it will throw an SQLEXCEPTION.
This is probably the case for failures where only one value differs.
Furthermore, there is a third scenario: both threads are scheduled to run
interleaved for each iteration (or even one thread completes all iterations
before the other starts). In this case, both will succeed without any error.
This is probably the case for the failure that reports two different values.
This patch addresses the failure in pushbuild by removing the error counting
and the printout (SELECT > 0) at the end of the test. A timeout should occur
if the error that the test is checking surfaces.
- Additional patch with improved protection by putting it all inside an "eval"
- Calling 'hostpath' on a truncated socket may also croak.
- Remove the need to create any directory parts of "path" inside the function.
- Fix problem with for example ./mtr --timer, caused by new version of "Getopt::Long"
- Evaluating the "$opt" variable as a string, returns the name of the parameter
to be modified instead of "Getopt::Long::Callback" which is the class name
In mtr.check_warnings, `text` was declares as type text, which is
64K, and when the server log grows larger than this, it would be
truncated, and then check_warnings was actually checking the
error messages of a previous test and complain warnings.
This patch fixed the problem by change the type of `text` to
mediumtext, which is 16M.
Log output of mysqltest when running check-testcase together
with errput. Remove --silent option for mysqltest when running
check-testcase/check-warnings
Problem 1: The test waits for an error in the slave sql thread,
then resolves the error and issues 'start slave'. However, there
is a gap between when the error is reported and the slave sql
thread stops. If this gap was long, the slave would still be
running when 'start slave' happened, so 'start slave' would fail
and cause a test failure.
Fix 1: Made wait_for_slave_sql_error wait for the slave to stop
instead of wait for error in the IO thread. After stopping, the
error code is verified. If the error code is wrong, debug info
is printed. To print debug info, the debug printing code in
wait_for_slave_param.inc was moved out to a new file,
show_rpl_debug_info.inc.
Problem 2: rpl_stm_mystery22 is a horrible name, the comments in
the file didn't explain anything useful, the test was generally
hard to follow, and the test was essentially duplicated between
rpl_stm_mystery22 and rpl_row_mystery22.
Fix 2: The test is about conflicts in the slave SQL thread,
hence I renamed the tests to rpl_{stm,row}_conflicts. Refactored
the test so that the work is done in
extra/rpl_tests/rpl_conflicts.inc, and
rpl.rpl_{row,stm}_conflicts merely sets some variables and then
sourced extra/rpl_tests/rpl_conflicts.inc.
The tests have been rewritten and comments added.
Problem 3: When calling wait_for_slave_sql_error.inc, you always
want to verify that the sql thread stops because of the expected
error and not because of some other error. Currently,
wait_for_slave_sql_error.inc allows the caller to omit the error
code, in which case all error codes are accepted.
Fix 3: Made wait_for_slave_sql_error.inc fail if no error code
is given. Updated rpl_filter_tables_not_exist accordingly.
Problem 4: rpl_filter_tables_not_exist had a typo, the dollar
sign was missing in a 'let' statement.
Fix 4: Added dollar sign.
Problem 5: When replicating from other servers than the one named
'master', the wait_for_slave_* macros were unable to print debug
info on the master.
Fix 5: Replace parameter $slave_keep_connection by
$master_connection.
Problem: when mtr tries to create a directory, and the target
exists but is a file instead of directory, it tries several times
to create the directory again before it fails.
Fix: make it check if the target exists and is a non-directory.
If server has not been initialized as a slave (by CHANGE MASTER), then
SHOW SLAVE STATUS will return an empty set, and caused the waiting for
Slave_IO_running or Slave_SQL_running to 'No' fail.
This patch fixed the problem by return immediately if slave is not
initialized in include/wait_for_slave_*_to_stop.inc.
mysqltest command 'shutdown_server' is supposed to shutdown the server
and wait for it to be gone, and kill it when timeout. But because the
arguments passed to my_kill were in the wrong order, 'shutdown_server'
does not wait nor kill the server at all. So after 'shutdown_server',
the server is still running, and the server may still accepting
connections.
Bug#38540 rpl_server_id2 uses show slave status unnecessarily
Slave did not perform any event recorded into the relay log from some
different master when it was started with --replicate-same-server-id.
The reason appeared to be a consequence of BUG#38734 which stopped the
sql thread at its startup time.
The real fixes for the current bug are in the patch for BUG#38734.
This changeset carries only a regression test for the bugs. Bug#38540
gets fixed too by means of eliminating an extra show slave status.
