Re: [HACKERS] snapbuild woes
От | Andrew Dunstan |
---|---|
Тема | Re: [HACKERS] snapbuild woes |
Дата | |
Msg-id | ac7104f5-f1a1-a7b1-2f57-8119a17f1120@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] snapbuild woes (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: