database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-11-03 09:13:20 +03:00
Code Activity

Raise some timeouts to 180s, in test code.

Browse Source 
Slow runs of buildfarm members chipmunk, hornet and mandrill saw the
shorter timeouts expire.  The 180s timeout in poll_query_until has been
trouble-free since 2a0f89cd71 introduced
it two years ago, so use 180s more widely.  Back-patch to 9.6, where the
first of these timeouts was introduced.

Reviewed by Michael Paquier.

Discussion: https://postgr.es/m/20181209001601.GC2973271@rfd.leadboat.com
This commit is contained in:
Noah Misch
2018-12-10 20:15:42 -08:00
parent 0f9fd7419a
commit 752278e774
2 changed files with 10 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
src/test/isolation/README
View File

@@ -108,8 +108,8 @@ Each step may contain commands that block until further action has been taken
deadlock). A test that uses this ability must manually specify valid deadlock). A test that uses this ability must manually specify valid
permutations, i.e. those that would not expect a blocked session to execute a permutations, i.e. those that would not expect a blocked session to execute a
command. If a test fails to follow that rule, isolationtester will cancel it command. If a test fails to follow that rule, isolationtester will cancel it
after 60 seconds. If the cancel doesn't work, isolationtester will exit after 180 seconds. If the cancel doesn't work, isolationtester will exit
uncleanly after a total of 75 seconds of wait time. Testing invalid uncleanly after a total of 200 seconds of wait time. Testing invalid
permutations should be avoided because they can make the isolation tests take permutations should be avoided because they can make the isolation tests take
a very long time to run, and they serve no useful testing purpose. a very long time to run, and they serve no useful testing purpose.

16
src/test/isolation/isolationtester.c
View File

@@ -768,15 +768,15 @@ try_complete_step(Step *step, int flags)
td += (int64) current_time.tv_usec - (int64) start_time.tv_usec; td += (int64) current_time.tv_usec - (int64) start_time.tv_usec;
/* /*
* After 60 seconds, try to cancel the query. * After 180 seconds, try to cancel the query.
* *
* If the user tries to test an invalid permutation, we don't want * If the user tries to test an invalid permutation, we don't want
* to hang forever, especially when this is running in the * to hang forever, especially when this is running in the
* buildfarm. So try to cancel it after a minute. This will * buildfarm. This will presumably lead to this permutation
* presumably lead to this permutation failing, but remaining * failing, but remaining permutations and tests should still be
* permutations and tests should still be OK. * OK.
*/ */
if (td > 60 * USECS_PER_SEC && !canceled) if (td > 180 * USECS_PER_SEC && !canceled)
{ {
PGcancel *cancel = PQgetCancel(conn); PGcancel *cancel = PQgetCancel(conn);
@@ -793,15 +793,15 @@ try_complete_step(Step *step, int flags)
} }
/* /*
* After 75 seconds, just give up and die. * After 200 seconds, just give up and die.
* *
* Since cleanup steps won't be run in this case, this may cause * Since cleanup steps won't be run in this case, this may cause
* later tests to fail. That stinks, but it's better than waiting * later tests to fail. That stinks, but it's better than waiting
* forever for the server to respond to the cancel. * forever for the server to respond to the cancel.
*/ */
if (td > 75 * USECS_PER_SEC) if (td > 200 * USECS_PER_SEC)
{ {
fprintf(stderr, "step %s timed out after 75 seconds\n", fprintf(stderr, "step %s timed out after 200 seconds\n",
step->name); step->name);
exit_nicely(); exit_nicely();
} }