From c1f58fac6c151fb96e1281bb968545f1dfd6550c Mon Sep 17 00:00:00 2001 From: Jelte Fennema Date: Fri, 19 Aug 2022 17:05:36 +0200 Subject: [PATCH] Don't run any isolation tests in parallel (#6212) By running isolation tests in parallel we're just asking for flaky tasks. The first test might temporarily block one of the commands in the second test, which we then detect as waiting like this: ```diff step s2-vacuum-analyze: VACUUM ANALYZE test_insert_vacuum; - + step s1-commit: COMMIT; +step s2-vacuum-analyze: <... completed> ``` Debugging flaky tests is also much harder when they are run in parallel. This PR starts running all our isolation tests sequentially. The reason for opening this PR was me seeing this failing test: https://app.circleci.com/pipelines/github/citusdata/citus/26194/workflows/ff57e2cf-8ac4-40fe-bc0c-74a7f8fecb53/jobs/740454 As well as having fixed a similar issue recently in #6122 (cherry picked from commit 85305b2773605920c24e740dfffa5895e9ed4e2f) --- src/test/regress/isolation_schedule | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/src/test/regress/isolation_schedule b/src/test/regress/isolation_schedule index 34b2b4a3c..52b5dc021 100644 --- a/src/test/regress/isolation_schedule +++ b/src/test/regress/isolation_schedule @@ -26,12 +26,15 @@ test: isolation_citus_dist_activity test: isolation_remove_coordinator test: isolation_insert_select_repartition -test: isolation_dml_vs_repair isolation_copy_placement_vs_copy_placement +test: isolation_dml_vs_repair +test: isolation_copy_placement_vs_copy_placement test: isolation_concurrent_dml test: isolation_data_migration -test: isolation_drop_shards isolation_copy_placement_vs_modification -test: isolation_insert_vs_vacuum isolation_transaction_recovery +test: isolation_drop_shards +test: isolation_copy_placement_vs_modification +test: isolation_insert_vs_vacuum +test: isolation_transaction_recovery test: isolation_progress_monitoring test: isolation_dump_local_wait_edges