MySQL Bugs: #43365: mysql-test: hook for adding calls to run after test is finished

Bug #43365	mysql-test: hook for adding calls to run after test is finished
Submitted:	4 Mar 2009 11:13	Modified:	10 Nov 2009 19:38
Reporter:	Jørgen Austvik	Email Updates:
Status:	Verified	Impact on me:	None
Category:	Tools: MTR / mysql-test-run	Severity:	S4 (Feature request)
Version:		OS:	Any
Assigned to:	Bjørn Munch	CPU Architecture:	Any

Description:
Some times (e.g. when you have a stress init test or a test that is also used in a stress test scenario), a test can not know when to clean up after itself (it does not know if it has been run for the last time or not).

I propose an expansion of the grammar in mysql-test, named "run-as-cleanup", "run-before-exit", "run-in-teardown", "exec-teardown" or similar, which take a string parameter.

The semantics are that the strings that are sent to "exec-teardown" will be pushed to a stack of strings, and after a test has been finished (but before checking for changes in the schema) will be popped off the stack and executed one after one.

For stress tests these strings will be executed as SQL statements after all the threads are finished executing their threads. 

Example:
---------8<----------------8<----------------8<-------
CREATE TABLE t1 (a INT);
--run-as-cleanup DROP TABLE t1;

CREATE VIEW v1 AS SELECT * FROM t1;
--run-as-cleanup DROP VIEW v1;
---------8<----------------8<----------------8<-------

Will:
---------8<----------------8<----------------8<-------
<generate before image of schema>
CREATE TABLE t1 (a INT);
CREATE VIEW v1 AS SELECT * FROM t1;
<run diff on result>
DROP VIEW v1;
DROP TABLE t1;
<generate after image of schema>
<diff schema images>
---------8<----------------8<----------------8<-------

How to repeat:
Write tests that have (and have to have) documented side effects and observe that mtr2 fails.

Suggested fix:
Add --exec-teardown or similar to the mysql-test language

Hi,

I propose a different solution.

Background:
1. Lets assume we are around the end of the
   execution of a test script.
   If we are able to detect that we are running in
   "stress" mode or not (= MTR was started with or
   without "--stress") by using the existing
   mysqltest language and/or SQL and the environment
   (content of env variables or files) than
   we could adjust our cleanup actions
   - running in "stress" mode -> do nothing
   - running not in "stress" mode -> do the cleanup
2. All stress testing related actions already happen
   under the control of MTR and partially the scripts.
   Therefore I think the necessary changes should
   happen within MTR and the scripts.
   The mysqltest application should be kept simple
   if possible.
   
Possible solution:
1. In MTR
   MTR sets and exports an environment variable
   with a name like MTR_STRESS which shows if
   we are running in stress mode before any
   mysqltest process is started.
2. Within the test
   if (`SELECT '$MTR_STRESS' <> '1')
   {
      --source <some path>/<name>_cleanup.test
   }

I wasn't aware of this bug intil it got assigned to be now.
I'm not quite sure what the actual problem is that one tries to solve here.

There is already a way to avoid the failure reported by MTR due to changes in schema etc.:

call mtr.force_restart();

This will cause a server restart after the testcase and thus avoid the test.

Would this solve the problem?