Don't run fast_default regression test in parallel with other tests.

Since it sets up an event trigger that would fire on DDL done by any
concurrent test script, the original scheduling is just an invitation
to irreproducible test failures.  (The fact that we found a bug through
exactly such irreproducible test failures doesn't really change the
calculus here: this script is a hazard to anything that runs in parallel
with it today or might be added to that parallel group in future.  No,
I don't believe that the trigger is protecting itself sufficiently to
avoid all possible trouble.)

Discussion: https://postgr.es/m/5767.1523995174@sss.pgh.pa.us

diff --git a/src/test/regress/parallel_schedule b/src/test/regress/parallel_schedule
index c07083bd448dd48739bb783459689674ebdd2305..16f979c8d93e07c478c2761e91c0dd0c2409390b 100644 (file)
--- a/src/test/regress/parallel_schedule
+++ b/src/test/regress/parallel_schedule
@@ -116,10 +116,12 @@ test: plancache limit plpgsql copy2 temp domain rangefuncs prepare without_oid c
 # ----------
 # Another group of parallel tests
 # ----------
-test: identity partition_join partition_prune reloptions hash_part indexing partition_aggregate fast_default
+test: identity partition_join partition_prune reloptions hash_part indexing partition_aggregate
 
 # event triggers cannot run concurrently with any test that runs DDL
 test: event_trigger
+# this test also uses event triggers, so likewise run it by itself
+test: fast_default
 
 # run stats by itself because its delay may be insufficient under heavy load
 test: stats

diff --git a/src/test/regress/serial_schedule b/src/test/regress/serial_schedule
index e6e6a4608b2aadeef1484047905efd6ac30a2b85..42632be67503a7b5565963f6de2411878c23dcaf 100644 (file)
--- a/src/test/regress/serial_schedule
+++ b/src/test/regress/serial_schedule
@@ -188,6 +188,6 @@ test: reloptions
 test: hash_part
 test: indexing
 test: partition_aggregate
-test: fast_default
 test: event_trigger
+test: fast_default
 test: stats