2 files changed, 10 insertions, 5 deletions
diff --git a/src/test/isolation/expected/deadlock-hard.out b/src/test/isolation/expected/deadlock-hard.out
index b4ce01962d6..7038972675d 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 1131ec1a97b..459a7a7ea24 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"