Skip site navigation (1) Skip section navigation (2)

Re: [COMMITTERS] pgsql: Fix brain fade in DefineIndex(): it was continuing to access the

From: ohp(at)pyrenet(dot)fr
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: [COMMITTERS] pgsql: Fix brain fade in DefineIndex(): it was continuing to access the
Date: 2007-08-30 13:03:56
Message-ID: Pine.UW2.4.53.0708301500210.16495@sun.pyrenet (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Hi all,
On Tue, 28 Aug 2007, Andrew Dunstan wrote:

> Date: Tue, 28 Aug 2007 12:34:46 -0400
> From: Andrew Dunstan <andrew(at)dunslane(dot)net>
> Newsgroups: pgsql.hackers
> Subject: Re: [COMMITTERS] pgsql: Fix brain fade in DefineIndex(): it was
>     continuing to access the
>
>
>
> Tom Lane wrote:
> > Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> >
> >> Tom Lane wrote:
> >>
> >>> This particular issue could be implemented just by adding
> >>> -DCLOBBER_CACHE_ALWAYS to CFLAGS (or CPPFLAGS if you want to be anal
> >>> about it).  I suppose that no new buildfarm mechanism is required ---
> >>> someone just needs to set up an animal configured that way, and
> >>> scheduled to run only maybe once a week or something like that.
> >>>
> >
> >
> >> Ah. Ok. That makes sense. How long does such a regression run usually take?
> >>
> >
> > On my x86_64 machine (dual 2.8GHz Xeon EM64T) it's on the order of two
> > or three hours --- I haven't timed it carefully, but somewhere along
> > there.  That's just for the core regression tests, I've never tried
> > contrib or PL tests.
> >
> > It should be a separate animal, and not something that an existing one
> > does every-so-often, or we might mistake anything it finds for an
> > irreproducible transient failure.  Consistent failures on the same
> > animal will stand out of the noise, though.
> >
> >
> >
>
>
> I tried this on a little P3 I have lying around:
>
> [andrew(at)marmaduke bf]$ ./run_build.pl --test --conf=figeater.conf
> Mon Aug 27 17:03:55 2007: buildfarm run for figeater:HEAD starting
> [17:03:55] checking out source ...
> [17:04:17] checking if build run needed ...
> [17:04:18] creating vpath build dir pgsql.11834 ...
> [17:04:18] running configure ...
> [17:06:06] running make ...
> [17:31:14] running make check ...
> [00:43:28] running make contrib ...
> Branch: HEAD
> Stage Contrib failed with status 2
>
>
> Good thing it failed - goodness only knows how long the extra runs would
> have taken :-)
>
> Does someone have a box with lots of grunt that can spare some cycles
> for a few hours once a week or so?
I've just configure centaur (CentOS 5) like this.
Do you need it for every version (8.1, 8.2) or just HEAD
Do you need it just once a week or every run?
I can also configure wharthog (unixware) like this if you need...
>
> cheers
>
> andrew
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faq
>
>

-- 
Olivier PRENANT        	        Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges                +33-5-61-50-97-01 (Fax)
31190 AUTERIVE                       +33-6-07-63-80-64 (GSM)
FRANCE                          Email: ohp(at)pyrenet(dot)fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2007-08-30 13:07:54
Subject: Re: testing more than one configuration on a single build machine
Previous:From: Gabor SzaboDate: 2007-08-30 12:37:22
Subject: testing more than one configuration on a single build machine

pgsql-committers by date

Next:From: Andrew DunstanDate: 2007-08-30 13:18:49
Subject: Re: [COMMITTERS] pgsql: Fix brain fade in DefineIndex(): it was continuing to access the
Previous:From: Tom LaneDate: 2007-08-30 05:27:29
Subject: pgsql: Fix int8mul so that overflow check is applied correctly for

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group