database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-10-18 04:29:09 +03:00
Code Activity

Still further tweaking of deadlock isolation tests.

Browse Source 
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.
This commit is contained in:
Tom Lane
2016-02-12 14:19:57 -05:00
parent 9c9782f066
commit d03130d378
2 changed files with 10 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
src/test/isolation/specs/deadlock-hard.spec
View File

@@ -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"