Make new deadlock isolation test more reproducible.

The original formulation of 4c9864b9b4
was extremely timing-sensitive, because it arranged for the deadlock
detector to be running (and possibly unblocking the current query)
at almost exactly the same time as isolationtester would be probing
to see if the query is blocked.  The committed expected-file assumed
that the deadlock detection would finish first, but we see the opposite
on both fast and slow buildfarm animals.  Adjust the deadlock timeout
settings to make it predictable that isolationtester *will* see the
query as waiting before deadlock detection unblocks it.

I used a 5s timeout for the same reasons mentioned in
a7921f71a3.
This commit is contained in:
Tom Lane 2016-02-11 11:59:11 -05:00
parent d9dc2b4149
commit b11d07b6a3
2 changed files with 13 additions and 11 deletions

View File

@ -16,7 +16,8 @@ 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 s8a1: LOCK TABLE a1;
step s8a1: LOCK TABLE a1; <waiting ...>
step s8a1: <... completed>
step s7a8: <... completed>
error in steps s8a1 s7a8: ERROR: deadlock detected
step s8c: COMMIT;

View File

@ -1,6 +1,7 @@
# This is a straightforward deadlock scenario. Since it involves more than
# two processes, the mainlock detector will find the problem and rollback the
# backend which discovers it.
# 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.
setup
{
@ -20,49 +21,49 @@ teardown
}
session "s1"
setup { BEGIN; SET deadlock_timeout = '10s'; }
setup { BEGIN; SET deadlock_timeout = '100s'; }
step "s1a1" { LOCK TABLE a1; }
step "s1a2" { LOCK TABLE a2; }
step "s1c" { COMMIT; }
session "s2"
setup { BEGIN; SET deadlock_timeout = '10s'; }
setup { BEGIN; SET deadlock_timeout = '100s'; }
step "s2a2" { LOCK TABLE a2; }
step "s2a3" { LOCK TABLE a3; }
step "s2c" { COMMIT; }
session "s3"
setup { BEGIN; SET deadlock_timeout = '10s'; }
setup { BEGIN; SET deadlock_timeout = '100s'; }
step "s3a3" { LOCK TABLE a3; }
step "s3a4" { LOCK TABLE a4; }
step "s3c" { COMMIT; }
session "s4"
setup { BEGIN; SET deadlock_timeout = '10s'; }
setup { BEGIN; SET deadlock_timeout = '100s'; }
step "s4a4" { LOCK TABLE a4; }
step "s4a5" { LOCK TABLE a5; }
step "s4c" { COMMIT; }
session "s5"
setup { BEGIN; SET deadlock_timeout = '10s'; }
setup { BEGIN; SET deadlock_timeout = '100s'; }
step "s5a5" { LOCK TABLE a5; }
step "s5a6" { LOCK TABLE a6; }
step "s5c" { COMMIT; }
session "s6"
setup { BEGIN; SET deadlock_timeout = '10s'; }
setup { BEGIN; SET deadlock_timeout = '100s'; }
step "s6a6" { LOCK TABLE a6; }
step "s6a7" { LOCK TABLE a7; }
step "s6c" { COMMIT; }
session "s7"
setup { BEGIN; SET deadlock_timeout = '10s'; }
setup { BEGIN; SET deadlock_timeout = '100s'; }
step "s7a7" { LOCK TABLE a7; }
step "s7a8" { LOCK TABLE a8; }
step "s7c" { COMMIT; }
session "s8"
setup { BEGIN; SET deadlock_timeout = '10ms'; }
setup { BEGIN; SET deadlock_timeout = '5s'; }
step "s8a8" { LOCK TABLE a8; }
step "s8a1" { LOCK TABLE a1; }
step "s8c" { COMMIT; }