Commit Graph

9 Commits

Author SHA1 Message Date
Nikita Mikhaylov
95dce88b40 Maybe better? 2024-02-21 17:55:30 +00:00
Anton Popov
01c10e1085 fix some tests 2023-12-11 17:08:01 +00:00
János Benjamin Antal
358846c0fb
Merge pull request #52852 from ClickHouse/maybe-fix-02352_rwlock
Try to fix 02352_rwlock
2023-08-07 11:02:53 +02:00
Nikolai Kochetov
eb93d34e8d Disable more tests for debug. 2023-08-01 15:39:56 +00:00
János Benjamin Antal
6859c2c7fe Try to fix 02352_rwlock 2023-08-01 14:40:13 +02:00
Alexey Milovidov
08a9d97de7 Fix tests 2023-05-07 19:40:43 +02:00
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