Re: [HACKERS] snapbuild woes - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: [HACKERS] snapbuild woes
Date
Msg-id ac7104f5-f1a1-a7b1-2f57-8119a17f1120@2ndQuadrant.com
Whole thread Raw
In response to Re: [HACKERS] snapbuild woes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On 05/01/2017 08:46 AM, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
>> On Fri, Apr 21, 2017 at 10:34:58PM -0700, Andres Freund wrote:
>>> ... I was wondering about adding
>>> a loop that simply runs for like 30s and then quits or such, but who
>>> knows.
>> If the probabilistic test catches the bug even 5% of the time in typical
>> configurations, the buildfarm will rapidly identify any regression.  I'd
>> choose a 7s test that detects the bug 5% of the time over a 30s test that
>> detects it 99% of the time.  (When I wrote src/bin/pgbench/t/001_pgbench.pl
>> for a probabilistic bug, I sized that test to finish in 1s and catch its bug
>> half the time.  In its case, only two buildfarm members were able to
>> demonstrate the original bug, so 5% detection would have been too low.)
> 30sec is kind of a big lump from a buildfarm standpoint, especially if
> you mean "it runs for 30s on my honkin' fast workstation".  I'm fine
> with individual tests that run for ~ 1sec.
>
> (This is top-of-mind for me right now because I've been looking around
> for ways to speed up the regression tests.)
>
>             


Yes, me too. We're getting a bit lazy about that - see thread nearby
that will let us avoid unnecessary temp installs among other things.


cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: [HACKERS] CTE inlining
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Bug in prepared statement cache invalidation?