summaryrefslogtreecommitdiff
path: root/mysql-test/t/multi_update2.test
Commit message (Collapse)AuthorAgeFilesLines
* Speed up `mtr --parallel=<lots>` by scheduling some slow tests earlier.unknown2011-01-031-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | The patch also fixes a race in rpl_stop_slave.test. On machines with lots of CPU and memory, something like `mtr --parallel=10` can speed up the test suite enormously. However, we have a few test cases that run for long (several minutes), and if we are unlucky and happen to schedule those towards the end of the test suite, we end up with most workers idle while waiting for the last slow test to end, significantly delaying the finish of the entire suite. Improve this by marking the offending tests as taking "long", and trying to schedule those tests early. This reduces the time towards the end of the test suite run where some workers are waiting with nothing to do for the remaining workers each to finish their last test. Also, the rpl_stop_slave test had a race which could cause it to take a 300 seconds debug_sync timeout; this is fixed. Testing on a 4-core 8GB machine, this patch speeds up the test suite with around 30% for --parallel=10 (debug build), allowing to run the entire suite in 5 minutes.
* Speed up of test suite:Michael Widenius2009-10-281-1/+2
| | | | - Added --disable_query_log ; begin ; .... commit; --enable_query_log around all while loops that does insert
* Test is very resource intensive under debug and valgrind runs.Davi Arnaut2009-06-081-5/+24
| | | | | | | | | Under a debug run, the trace file grows to a few gigabytes. Under valgrind, takes more then 20 minutes due to the high number of insert statements. mysql-test/t/multi_update2.test: Skip under --valgrind and --debug.
* Test is very resource intensive under debug and valgrind runs.Davi Arnaut2009-06-081-3/+16
| | | | | | | | | Under a debug run, the trace file grows to a few gigabytes. Under valgrind, takes more then 20 minutes due to the high number of insert statements. mysql-test/t/multi_update2.test: Skip under --valgrind and --debug.
* Fix for Bug#26890 main.multi_update times outMatthias Leich2008-11-191-0/+43
The test itself is not faulty. The testcase timeout problem happens if this IMHO mid size resource (space in vardir, virtual memory, amount of disk I/O) consuming test meets a weak (excessive disk I/O caused by parallel applications or paging) testing box. The modifications: - Move the most time and disk I/O consuming subtest for Bug 1820 into its own script (multi_update2) This will reduce the likelihood that we exceed the testcase timeout. - Replace error numbers with error names - Minor improvements of the formatting -