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

From Andres Freund
Subject Re: [HACKERS] snapbuild woes
Date
Msg-id 20170501160918.j27fvngzuwspg7d6@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] snapbuild woes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] snapbuild woes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2017-05-01 08:46:47 -0400, 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.

I was more thinking of pgench -T$XX, rather than constant number of
iterations.  I currently can reproduce the issues within like 3-4
minutes, so 5s is probably not quite sufficient to get decent coverage.


- Andres



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] PQhost may return socket dir for network connection
Next
From: Kevin Grittner
Date:
Subject: Re: [HACKERS] transition table behavior with inheritance appearsbroken (was: Declarative partitioning - another take)