8000 Honor PGCTLTIMEOUT environment variable for pg_regress' startup wait. · prmdeveloper/postgres@f05ac71 · GitHub
[go: up one dir, main page]

Skip to content

Commit f05ac71

Browse files
committed
Honor PGCTLTIMEOUT environment variable for pg_regress' startup wait.
In commit 2ffa869 we made pg_ctl recognize an environment variable PGCTLTIMEOUT to set the default timeout for starting and stopping the postmaster. However, pg_regress uses pg_ctl only for the "stop" end of that; it has bespoke code for starting the postmaster, and that code has historically had a hard-wired 60-second timeout. Further buildfarm experience says it'd be a good idea if that timeout were also controlled by PGCTLTIMEOUT, so let's make it so. Like the previous patch, back-patch to all active branches. Discussion: <13969.1461191936@sss.pgh.pa.us>
1 parent ef35afa commit f05ac71

File tree

1 file changed

+21
-6
lines changed

1 file changed

+21
-6
lines changed

src/test/regress/pg_regress.c

Lines changed: 21 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -2377,6 +2377,8 @@ regression_main(int argc, char *argv[], init_function ifunc, test_function tfunc
23772377
{
23782378
FILE *pg_conf;
23792379
_stringlist *sl;
2380+
const char *env_wait;
2381+
int wait_seconds;
23802382

23812383
/*
23822384
* Prepare the temp installation
@@ -2555,11 +2557,23 @@ regression_main(int argc, char *argv[], init_function ifunc, test_function tfunc
25552557
}
25562558

25572559
/*
2558-
* Wait till postmaster is able to accept connections (normally only a
2559-
* second or so, but Cygwin is reportedly *much* slower). Don't wait
2560-
* forever, however.
2560+
* Wait till postmaster is able to accept connections; normally this
2561+
* is only a second or so, but Cygwin is reportedly *much* slower, and
2562+
* test builds using Valgrind or similar tools might be too. Hence,
2563+
* allow the default timeout of 60 seconds to be overridden from the
2564+
* PGCTLTIMEOUT environment variable.
25612565
*/
2562-
for (i = 0; i < 60; i++)
2566+
env_wait = getenv("PGCTLTIMEOUT");
2567+
if (env_wait != NULL)
2568+
{
2569+
wait_seconds = atoi(env_wait);
2570+
if (wait_seconds <= 0)
2571+
wait_seconds = 60;
2572+
}
2573+
else
2574+
wait_seconds = 60;
2575+
2576+
for (i = 0; i < wait_seconds; i++)
25632577
{
25642578
/* Done if psql succeeds */
25652579
if (system(buf2) == 0)
@@ -2580,9 +2594,10 @@ regression_main(int argc, char *argv[], init_function ifunc, test_function tfunc
25802594

25812595
pg_usleep(1000000L);
25822596
}
2583-
if (i >= 60)
2597+
if (i >= wait_seconds)
25842598
{
2585-
fprintf(stderr, _("\n%s: postmaster did not respond within 60 seconds\nExamine %s/log/postmaster.log for the reason\n"), progname, outputdir);
2599+
fprintf(stderr, _("\n%s: postmaster did not respond within %d seconds\nExamine %s/log/postmaster.log for the reason\n"),
2600+
progname, wait_seconds, outputdir);
25862601

25872602
/*
25882603
* If we get here, the postmaster is probably wedged somewhere in

0 commit comments

Comments
 (0)
0