Commit Graph

3 Commits

Author SHA1 Message Date
Robert Schulze
fe8f84dccc
Exclude slow tests from fasttest profile
99% of all tests in the fasttest profile run in one sec or less. The
excluded tests take 10 sec or more (the slowest being
02271_replace_partition_many_tables with 30 sec).

Estimated savings: 7 min
2022-09-07 15:57:29 +00:00
Azat Khuzhin
8b08d56473 tests: fix 02352_rwlock flakiness
It is possible that the next after INSERT query will be executed only
when INSERT finished, it is unlikely, but it happened few times on CI
[1]:

    2022.08.05 19:32:13.964046 [ 1565 ] {insert-qjnxxoaebk} <Debug> executeQuery: (from [::1]:57512) (comment: 02352_rwlock.sh) INSERT INTO test_7ybr6x_ordinary.data_02352 SELECT sleepEachRow(1) FROM numbers(20) GROUP BY number (stage: Complete)
    ...
    2022.08.05 19:32:14.945738 [ 1594 ] {245b7446-58da-452b-9669-55dad643bc34} <Debug> executeQuery: (from [::1]:57516) (comment: 02352_rwlock.sh) select count() from system.processes where query_id = 'insert-qjnxxoaebk' (stage: Complete)
    ...
    2022.08.05 19:32:33.997257 [ 1565 ] {insert-qjnxxoaebk} <Debug> TCPHandler: Processed in 20.056755494 sec.
    ...
    2022.08.05 19:32:34.614789 [ 908 ] {3be7ade3-6461-4906-8767-7cc11f83a0b8} <Debug> executeQuery: (from [::1]:57522) (comment: 02352_rwlock.sh) select count() from system.processes where query_id = 'drop-zoyhjyewja' (stage: Complete)
    ...
    2022.08.05 19:32:34.674039 [ 1175 ] {drop-zoyhjyewja} <Debug> executeQuery: (from [::1]:57528) (comment: 02352_rwlock.sh) DROP TABLE test_7ybr6x_ordinary.data_02352 SYNC (stage: Complete)
    ...

  [1]: https://s3.amazonaws.com/clickhouse-test-reports/39826/8e545958495937c6c6e61951601a6470119d0813/stateless_tests__debug__[1/3].html

And to avoid flakiness in this case, add a retry loop and no-parallel
tag.

Refs: #38864
Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>
2022-08-06 20:34:04 +03:00
Azat Khuzhin
98cd92017e Fix waiting of shared lock after exclusive lock failure
When WRITE lock attemp fails (exclusive lock for ALTER/DELETE), and
there are multiple READ locks (shared lock for SELECT/INSERT), i.e. one
INSERT is in progress and one SELECT is queued after ALTER/DELETE
started but before it fails, this SELECT will wait until INSERT will
finishes.

This happens because in case of WRITE lock failure it does not notify
the next READ lock that can be acquired.

Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>
2022-07-05 19:12:47 +03:00