tarantool / tarantool / 12493901887

88%

master: 88%

push

github

test: speedup and stabilize the gh_7605_qsort_recovery test

The test used to take around 180 seconds in debug build and was quite
flaky.

When the test was introduced in commit e1d961708504 ("Fix a bug in
qsort") it was stated that such a long test with 2 million keys was needed
to reproduce the bug.

Since the test introduction our sort implementation was rewritten in
commit ec34bf7ba3ea ("core: introduce sample sort algorithm") and
commit 4f617b702f0f ("box: introduce memtx_sort_threads config parameter").

Now multithread sort is used as long as there are more than a 1024 keys
to sort, so such a huge test seems unnecessary.

Let's reduce test size to 20000 keys from 2000000 and make the test code
yield every 1000 iterations instead of 10000, which is a more common
practice.

When running the test a lot times in parallel the fiber slice check may
still fail during index correctness check, so set fiber slice there as
well.

Now the test runs around 6 seconds in debug build and may be removed
from long-run list.

The test still spots the original problem in case it appears which can
be verified by reverting the fix from the original commit.

Closes #10961

NO_CHANGELOG=test
NO_DOC=test

(cherry picked from commit cfc6b4a27)

69680 of 123532 branches covered (56.41%)

102662 of 117482 relevant lines covered (87.39%)

2368556.12 hits per line