Make new deadlock isolation test more reproducible.
The original formulation of 4c9864b9b4d87d02f07f40bb27976da737afdcab
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
a7921f71a3c747141344d8604f6a6d7b4cddb2a9.
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/b11d07b6a3fc64904731e3b9a467a2567bc7dcdb
Modified Files
--------------
src/test/isolation/expected/deadlock-hard.out | 3 ++-
src/test/isolation/specs/deadlock-hard.spec | 21 +++++++++++----------
2 files changed, 13 insertions(+), 11 deletions(-)
