From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 11 Feb 2016 16:59:11 +0000 (-0500)
Subject: Make new deadlock isolation test more reproducible.
X-Git-Tag: REL9_6_BETA1~719
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=b11d07b6a3fc64904731e3b9a467a2567bc7dcdb;p=postgresql

Make new deadlock isolation test more reproducible.

The original formulation of 4c9864b9b4d87d02f07f40bb27976da737afdcab
was extremely timing-sensitive, because it arranged for the deadlock
detector to be running (and possibly unblocking the current query)
at almost exactly the same time as isolationtester would be probing
to see if the query is blocked.  The committed expected-file assumed
that the deadlock detection would finish first, but we see the opposite
on both fast and slow buildfarm animals.  Adjust the deadlock timeout
settings to make it predictable that isolationtester *will* see the
query as waiting before deadlock detection unblocks it.

I used a 5s timeout for the same reasons mentioned in
a7921f71a3c747141344d8604f6a6d7b4cddb2a9.
---

diff --git a/src/test/isolation/expected/deadlock-hard.out b/src/test/isolation/expected/deadlock-hard.out
index cb25f75d28..b4ce01962d 100644
--- a/src/test/isolation/expected/deadlock-hard.out
+++ b/src/test/isolation/expected/deadlock-hard.out
@@ -16,7 +16,8 @@ step s4a5: LOCK TABLE a5; <waiting ...>
 step s5a6: LOCK TABLE a6; <waiting ...>
 step s6a7: LOCK TABLE a7; <waiting ...>
 step s7a8: LOCK TABLE a8; <waiting ...>
-step s8a1: LOCK TABLE a1;
+step s8a1: LOCK TABLE a1; <waiting ...>
+step s8a1: <... completed>
 step s7a8: <... completed>
 error in steps s8a1 s7a8: ERROR:  deadlock detected
 step s8c: COMMIT;
diff --git a/src/test/isolation/specs/deadlock-hard.spec b/src/test/isolation/specs/deadlock-hard.spec
index a6daba374a..1131ec1a97 100644
--- a/src/test/isolation/specs/deadlock-hard.spec
+++ b/src/test/isolation/specs/deadlock-hard.spec
@@ -1,6 +1,7 @@
 # This is a straightforward deadlock scenario.  Since it involves more than
-# two processes, the mainlock detector will find the problem and rollback the
-# backend which discovers it.
+# two processes, the main lock detector will find the problem and rollback
+# the session that first discovers it.  Set deadlock_timeout in each session
+# so that it's predictable which session fails.
 
 setup
 {
@@ -20,49 +21,49 @@ teardown
 }
 
 session "s1"
-setup		{ BEGIN; SET deadlock_timeout = '10s'; }
+setup		{ BEGIN; SET deadlock_timeout = '100s'; }
 step "s1a1"	{ LOCK TABLE a1; }
 step "s1a2"	{ LOCK TABLE a2; }
 step "s1c"	{ COMMIT; }
 
 session "s2"
-setup		{ BEGIN; SET deadlock_timeout = '10s'; }
+setup		{ BEGIN; SET deadlock_timeout = '100s'; }
 step "s2a2"	{ LOCK TABLE a2; }
 step "s2a3"	{ LOCK TABLE a3; }
 step "s2c"	{ COMMIT; }
 
 session "s3"
-setup		{ BEGIN; SET deadlock_timeout = '10s'; }
+setup		{ BEGIN; SET deadlock_timeout = '100s'; }
 step "s3a3"	{ LOCK TABLE a3; }
 step "s3a4"	{ LOCK TABLE a4; }
 step "s3c"	{ COMMIT; }
 
 session "s4"
-setup		{ BEGIN; SET deadlock_timeout = '10s'; }
+setup		{ BEGIN; SET deadlock_timeout = '100s'; }
 step "s4a4"	{ LOCK TABLE a4; }
 step "s4a5"	{ LOCK TABLE a5; }
 step "s4c"	{ COMMIT; }
 
 session "s5"
-setup		{ BEGIN; SET deadlock_timeout = '10s'; }
+setup		{ BEGIN; SET deadlock_timeout = '100s'; }
 step "s5a5"	{ LOCK TABLE a5; }
 step "s5a6"	{ LOCK TABLE a6; }
 step "s5c"	{ COMMIT; }
 
 session "s6"
-setup		{ BEGIN; SET deadlock_timeout = '10s'; }
+setup		{ BEGIN; SET deadlock_timeout = '100s'; }
 step "s6a6"	{ LOCK TABLE a6; }
 step "s6a7"	{ LOCK TABLE a7; }
 step "s6c"	{ COMMIT; }
 
 session "s7"
-setup		{ BEGIN; SET deadlock_timeout = '10s'; }
+setup		{ BEGIN; SET deadlock_timeout = '100s'; }
 step "s7a7"	{ LOCK TABLE a7; }
 step "s7a8"	{ LOCK TABLE a8; }
 step "s7c"	{ COMMIT; }
 
 session "s8"
-setup		{ BEGIN; SET deadlock_timeout = '10ms'; }
+setup		{ BEGIN; SET deadlock_timeout = '5s'; }
 step "s8a8"	{ LOCK TABLE a8; }
 step "s8a1"	{ LOCK TABLE a1; }
 step "s8c"	{ COMMIT; }