rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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.
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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
src/test/isolation/expected/deadlock-hard.out
View File

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

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"