From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Failed test 'psql query died successfully after SIGQUIT' |
Date: | 2018-01-29 04:35:56 |
Message-ID: | 8469.1517200556@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> Does anyone have any thoughts on why Travis CI might be failing
> occasionally as shown below, but the build farm apparently doesn't?
> It's not alien technology, it's just Ubuntu Linux running on a virtual
> machine. One thing that it does slightly differently is "make
> -Otarget -j3 check-world" but I don't see why -j3 would break
> something like that specifically, except perhaps by overloading the
> system in a way that affects timing.
Quite a few of us use -jsomething with make check-world, so I doubt
that that's an issue per se. I have no idea what -Otarget means in
this context though, and neither does "info make".
> # aborting wait: program timed out
Hmm -- looking at src/test/recovery/t/013_crash_restart.pl, that
message comes out if this timer expires:
# To avoid hanging while expecting some specific input from a psql
# instance being driven by us, add a timeout high enough that it
# should never trigger even on very slow machines, unless something
# is really wrong.
my $psql_timeout = IPC::Run::timer(60);
so in other words, all you need for this failure is for
013_crash_restart.pl to take more than 60 seconds (per-command, I think,
not total). I find the comment's optimism about that being impossible
rather naive :-(, even if the test does take only a couple of seconds on
typical modern hardware. I see in the buildfarm that skink takes >240
seconds ...
If you can easily experiment with changing that limit to 120 or 180
seconds, or can measure how long the test takes when it passes, that'd
be useful info.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-01-29 04:43:48 | Re: [HACKERS] GnuTLS support |
Previous Message | Thomas Munro | 2018-01-29 04:34:21 | Re: [HACKERS] Secondary index access optimizations |