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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-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

Browse pgsql-committers by date

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

Browse pgsql-hackers by date

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