Further tweaking of deadlock isolation tests.

The new deadlock-soft-2 test has a timing dependency too: it supposes
that isolationtester will detect step s1b as waiting before the deadlock
detector runs and grants it the lock.  Adjust deadlock_timeout to ensure
that that's true even in CLOBBER_CACHE_ALWAYS builds, where the wait
detection query is quite slow.  Per buildfarm member jaguarundi.
This commit is contained in:
Tom Lane 2016-02-11 23:21:33 -05:00
parent f144f73242
commit caefc11ef6
1 changed files with 10 additions and 4 deletions

View File

@ -2,6 +2,12 @@
# jump over both s3 and s4 and acquire the lock on a2 immediately,
# since s3 and s4 are hard-blocked on a1.
# The expected output for this test assumes that isolationtester will
# detect step s1b as waiting before the deadlock detector runs and
# releases s1 from its blocked state. To leave enough time for that
# to happen even in very slow (CLOBBER_CACHE_ALWAYS) cases, we must
# increase deadlock_timeout.
setup
{
CREATE TABLE a1 ();
@ -14,24 +20,24 @@ teardown
}
session "s1"
setup { BEGIN; }
setup { BEGIN; SET deadlock_timeout = '5s'; }
step "s1a" { LOCK TABLE a1 IN SHARE UPDATE EXCLUSIVE MODE; }
step "s1b" { LOCK TABLE a2 IN SHARE UPDATE EXCLUSIVE MODE; }
step "s1c" { COMMIT; }
session "s2"
setup { BEGIN; }
setup { BEGIN; SET deadlock_timeout = '100s'; }
step "s2a" { LOCK TABLE a2 IN ACCESS SHARE MODE; }
step "s2b" { LOCK TABLE a1 IN SHARE UPDATE EXCLUSIVE MODE; }
step "s2c" { COMMIT; }
session "s3"
setup { BEGIN; }
setup { BEGIN; SET deadlock_timeout = '100s'; }
step "s3a" { LOCK TABLE a2 IN ACCESS EXCLUSIVE MODE; }
step "s3c" { COMMIT; }
session "s4"
setup { BEGIN; }
setup { BEGIN; SET deadlock_timeout = '100s'; }
step "s4a" { LOCK TABLE a2 IN ACCESS EXCLUSIVE MODE; }
step "s4c" { COMMIT; }