From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 12 Feb 2016 19:19:57 +0000 (-0500)
Subject: Still further tweaking of deadlock isolation tests.
X-Git-Tag: REL9_6_BETA1~705
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=d03130d378b5fb071d231a7822784ad87268583a;p=postgresql

Still further tweaking of deadlock isolation tests.

It turns out that there is a second race condition in the new deadlock-hard
test: once the deadlock detector fires, it's uncertain whether step s7a8 or
step s8a1 will report first, because killing s8's transaction unblocks s7.
So far, s7 has only been seen to report first in CLOBBER_CACHE_ALWAYS
builds, but it's pretty reproducible there, and in theory it should
sometimes occur in normal builds too.  If s7 were a bit slower than usual,
that could also break the test, since the existing expected-file assumes
that we'll see s7a8 report the first time we check it after s8a1 completes.
To fix, add a post-lock delay to s7a8.
---

diff --git a/src/test/isolation/expected/deadlock-hard.out b/src/test/isolation/expected/deadlock-hard.out
index b4ce01962d..7038972675 100644
--- a/src/test/isolation/expected/deadlock-hard.out
+++ b/src/test/isolation/expected/deadlock-hard.out
@@ -15,12 +15,15 @@ step s3a4: LOCK TABLE a4; <waiting ...>
 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 s7a8: LOCK TABLE a8; SELECT pg_sleep(5); <waiting ...>
 step s8a1: LOCK TABLE a1; <waiting ...>
 step s8a1: <... completed>
-step s7a8: <... completed>
-error in steps s8a1 s7a8: ERROR:  deadlock detected
+ERROR:  deadlock detected
 step s8c: COMMIT;
+step s7a8: <... completed>
+pg_sleep       
+
+               
 step s7c: COMMIT;
 step s6a7: <... completed>
 step s6c: COMMIT;
diff --git a/src/test/isolation/specs/deadlock-hard.spec b/src/test/isolation/specs/deadlock-hard.spec
index 1131ec1a97..459a7a7ea2 100644
--- a/src/test/isolation/specs/deadlock-hard.spec
+++ b/src/test/isolation/specs/deadlock-hard.spec
@@ -1,7 +1,9 @@
 # This is a straightforward deadlock scenario.  Since it involves more than
 # 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.
+# so that it's predictable which session fails.  Also, when s8 fails and
+# rolls back, it unblocks s7, so that there is a race as to whether s7a8
+# or s8a1 will report first.  Add a delay in s7a8 to make that predictable.
 
 setup
 {
@@ -59,7 +61,7 @@ step "s6c"	{ COMMIT; }
 session "s7"
 setup		{ BEGIN; SET deadlock_timeout = '100s'; }
 step "s7a7"	{ LOCK TABLE a7; }
-step "s7a8"	{ LOCK TABLE a8; }
+step "s7a8"	{ LOCK TABLE a8; SELECT pg_sleep(5); }
 step "s7c"	{ COMMIT; }
 
 session "s8"