Further tweaking of deadlock isolation tests.

The new deadlock-soft-2 test has a timing dependency too: it supposes
that isolationtester will detect step s1b as waiting before the deadlock
detector runs and grants it the lock.  Adjust deadlock_timeout to ensure
that that's true even in CLOBBER_CACHE_ALWAYS builds, where the wait
detection query is quite slow.  Per buildfarm member jaguarundi.

1 files changed, 10 insertions, 4 deletions

diff --git a/src/test/isolation/specs/deadlock-soft-2.spec b/src/test/isolation/specs/deadlock-soft-2.spec
index 044921c05d0..46b73bc0823 100644
--- a/src/test/isolation/specs/deadlock-soft-2.spec
+++ b/src/test/isolation/specs/deadlock-soft-2.spec
@@ -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; }