Re: PGCTLTIMEOUT in pg_regress, or skink versus the clock

Noah Misch <noah@leadboat.com> writes:
> On Wed, Apr 20, 2016 at 06:38:56PM -0400, Tom Lane wrote:
>> I am thinking that we missed a bet in commit 2ffa86962077c588
>> et al, and that pg_regress's hard-wired 60-second start timeout ought to
>> be overridable from an environment variable just as pg_ctl's timeout is.
>> It might as well be the same environment variable, so I propose the
>> attached patch.

>> Any objections?

> Looks reasonable.

Pushed.

I did some more testing here and concluded that slow postmaster startup is
almost certainly the right explanation for skink's problems.  On my
otherwise-idle workstation, postmaster startup under valgrind takes about
10 seconds, of which six or seven seem to involve valgrind just collecting
its thoughts :-(.  The postmaster's socket file does not appear until nine
seconds in, and then by ten seconds it is ready to accept connections.
So that's how come I see just one "FATAL: the database system is starting
up" log entry --- pg_regress's previous eight launches of pg_ctl just failed
with "no such socket file".  So I now think the observed failures on skink
can be explained by supposing that valgrind sometimes takes around a
minute to start up on that platform.  The skink log I quoted before would
fit with the postmaster almost but not quite reaching "ready" status
before pg_ctl's timeout expires.  The other two skink failures actually
have empty postmaster log files, suggesting that valgrind was so slow that
we didn't even get to the "database system was shut down" log message.
        regards, tom lane