From d03130d378b5fb071d231a7822784ad87268583a Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Fri, 12 Feb 2016 14:19:57 -0500 Subject: [PATCH] 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. --- src/test/isolation/expected/deadlock-hard.out | 9 ++++++--- src/test/isolation/specs/deadlock-hard.spec | 6 ++++-- 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 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; step s4a5: LOCK TABLE a5; step s5a6: LOCK TABLE a6; step s6a7: LOCK TABLE a7; -step s7a8: LOCK TABLE a8; +step s7a8: LOCK TABLE a8; SELECT pg_sleep(5); step s8a1: LOCK TABLE a1; 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"