postgres
diff --git a/‎src/test/isolation/specs/deadlock-soft-2.spec
Copy file name to clipboardExpand all lines: src/test/isolation/specs/deadlock-soft-2.spec
+10-4Lines changed: 10 additions & 4 deletions b/‎src/test/isolation/specs/deadlock-soft-2.spec
Copy file name to clipboardExpand all lines: src/test/isolation/specs/deadlock-soft-2.spec
+10-4Lines changed: 10 additions & 4 deletions
@@ -2,6 +2,12 @@
 # jump over both s3 and s4 and acquire the lock on a2 immediately,
 # since s3 and s4 are hard-blocked on a1.
 
+# The expected output for this test assumes that isolationtester will
+# detect step s1b as waiting before the deadlock detector runs and
+# releases s1 from its blocked state.  To leave enough time for that
+# to happen even in very slow (CLOBBER_CACHE_ALWAYS) cases, we must
+# increase deadlock_timeout.
+
 setup
 {
   CREATE TABLE a1 ();
@@ -14,24 +20,24 @@ teardown
 }
 
 session "s1"
-setup		{ BEGIN; }
+setup		{ BEGIN; SET deadlock_timeout = '5s'; }
 step "s1a"	{ LOCK TABLE a1 IN SHARE UPDATE EXCLUSIVE MODE; }
 step "s1b"	{ LOCK TABLE a2 IN SHARE UPDATE EXCLUSIVE MODE; }
 step "s1c"	{ COMMIT; }
 
 session "s2"
-setup		{ BEGIN; }
+setup		{ BEGIN; SET deadlock_timeout = '100s'; }
 step "s2a" 	{ LOCK TABLE a2 IN ACCESS SHARE MODE; }
 step "s2b" 	{ LOCK TABLE a1 IN SHARE UPDATE EXCLUSIVE MODE; }
 step "s2c"	{ COMMIT; }
 
 session "s3"
-setup		{ BEGIN; }
+setup		{ BEGIN; SET deadlock_timeout = '100s'; }
 step "s3a"	{ LOCK TABLE a2 IN ACCESS EXCLUSIVE MODE; }
 step "s3c"	{ COMMIT; }
 
 session "s4"
-setup		{ BEGIN; }
+setup		{ BEGIN; SET deadlock_timeout = '100s'; }
 step "s4a"	{ LOCK TABLE a2 IN ACCESS EXCLUSIVE MODE; }
 step "s4c"	{ COMMIT; }