SEO

Andrew Dunstan <andrew@dunslane.net> writes:
> [redirected to -hackers]

> Tom Lane wrote:
>> Found by trying to run the regression tests with CLOBBER_CACHE_ALWAYS enabled.
>> Maybe we should try to do that on a regular basis --- it's awfully slow,
>> but perhaps some fast buildfarm machine could do it once in awhile.

> We currently don't have any way of providing for settings other than via
> the configure script options. We could in theory make provision for
> adding stuff to pg_config_manual.h, although it would be a bit more
> difficult in the vpath (I guess for vpath we could just blow that file
> away along with the files bison, flex etc. lob in the repo).

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.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>
>> [redirected to -hackers]
>>
>
>
>> Tom Lane wrote:
>>
>>> Found by trying to run the regression tests with CLOBBER_CACHE_ALWAYS enabled.
>>> Maybe we should try to do that on a regular basis --- it's awfully slow,
>>> but perhaps some fast buildfarm machine could do it once in awhile.
>>>
>
>
>> We currently don't have any way of providing for settings other than via
>> the configure script options. We could in theory make provision for
>> adding stuff to pg_config_manual.h, although it would be a bit more
>> difficult in the vpath (I guess for vpath we could just blow that file
>> away along with the files bison, flex etc. lob in the repo).
>>
>
> 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?

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Andrew Dunstan <andrew@dunslane.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.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.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@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?

cheers

andrew


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Hi all,
On Tue, 28 Aug 2007, Andrew Dunstan wrote:

> Date: Tue, 28 Aug 2007 12:34:46 -0400
> From: Andrew Dunstan <andrew@dunslane.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@dunslane.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@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@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

ohp@pyrenet.fr wrote:
>>
>> 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...
>
>

I have no idea - probably just HEAD, but Tom will have a better idea :-)
I imagine once a week would do, but as he says it should be a separate
animal, not an occasional change in an existing animal. So don't change
your existing buildfarm members please.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Andrew Dunstan <andrew@dunslane.net> writes:
> ohp@pyrenet.fr wrote:
>> 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...

> I have no idea - probably just HEAD, but Tom will have a better idea :-)

HEAD only is enough IMHO. If we find any bugs it should be pretty
obvious whether they need to be back-patched.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

ohp@pyrenet.fr writes:
> Ok, do you need it on unixware?
> do you need it more than once a week?

No, and no.

> FYI, centaurc is running make check for 3 hours now and has'nt finished!

You're finding out why I suggested a really low duty cycle ;-)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Hi Tom
On Thu, 30 Aug 2007, Tom Lane wrote:

> Date: Thu, 30 Aug 2007 10:04:34 -0400
> From: Tom Lane <tgl@sss.pgh.pa.us>
> To: Andrew Dunstan <andrew@dunslane.net>
> Cc: ohp@pyrenet.fr, PostgreSQL-development <pgsql-hackers@postgresql.org>
> Subject: Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix brain fade in
> DefineIndex(): it was continuing to access the
>
> Andrew Dunstan <andrew@dunslane.net> writes:
> > ohp@pyrenet.fr wrote:
> >> 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...
>
> > I have no idea - probably just HEAD, but Tom will have a better idea :-)
>
> HEAD only is enough IMHO. If we find any bugs it should be pretty
> obvious whether they need to be back-patched.
>
Ok, do you need it on unixware?
do you need it more than once a week?
FYI, centaurc is running make check for 3 hours now and has'nt finished!
Regards
> regards, tom lane
>

--
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@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

ohp@pyrenet.fr wrote:
> Ok, do you need it on unixware?
> do you need it more than once a week?
> FYI, centaurc is running make check for 3 hours now and has'nt finished!
>
>

The platform probably doesn't matter so much, I suspect. Once a week on
a separately registered animal should be fine. Whatever you have that's
fastest.

And don't be surprised how long it takes - "make check" on my little
PIII/FC5 box took 7 hours.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match