Re: Failed test 'psql query died successfully after SIGQUIT' - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Failed test 'psql query died successfully after SIGQUIT'
Date
Msg-id 8469.1517200556@sss.pgh.pa.us
Whole thread Raw
In response to Failed test 'psql query died successfully after SIGQUIT'  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: Failed test 'psql query died successfully after SIGQUIT'
List pgsql-hackers
Thomas Munro <thomas.munro@enterprisedb.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


pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [HACKERS] Secondary index access optimizations
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] GnuTLS support