-DCLOBBER_CACHE_ALWAYS build takes far longer than before

On Sun, 20 Apr 2008, Guillaume Smet wrote:

Date: Sun, 20 Apr 2008 16:23:47 +0200
From: Guillaume Smet <guillaume.smet@gmail.com>
To: pgsql-hackers list <pgsql-hackers@postgresql.org>, ohp@pyrenet.fr
Subject: -DCLOBBER_CACHE_ALWAYS build takes far longer than before

Hi all,

While working on our network problems to send the full build result to
the buildfarm server, I just saw that a full buildfarm run with
-DCLOBBER_CACHE_ALWAYS option takes nearly 2 hours more than before
(from ~ 5h40 to 7h30).

This phenomenon has started with this run:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=pigeon&amp;dt=2008-04-12%2008:00:02

which has taken into account these commits:
pgsql/README 1.35
pgsql/contrib/ltree/ltree_io.c 1.15
pgsql/src/backend/parser/parse_type.c 1.95
pgsql/src/backend/utils/adt/tsquery.c 1.17
pgsql/src/backend/utils/adt/arrayfuncs.c 1.143
pgsql/src/backend/utils/adt/geo_ops.c 1.100
pgsql/src/backend/utils/mmgr/aset.c 1.77
pgsql/src/port/dirmod.c 1.53
pgsql/src/include/pg_config_manual.h 1.31
pgsql/src/include/port.h 1.120
pgsql/doc/TODO 1.2415
pgsql/doc/src/FAQ/TODO.html 1.921

The additional time is spread like this:
make check: 40 minutes
make installcheck: 34 minutes
make contrib installcheck: 10 minutes

I don't know if it's normal or not but I thought it's worth
mentioning. The standard build run on the same box isn't affected.

Olivier, do you have the same behaviour with jaguar?

Yes I do!
--
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)

"Guillaume Smet" <guillaume.smet@gmail.com> writes:

While working on our network problems to send the full build result to
the buildfarm server, I just saw that a full buildfarm run with
-DCLOBBER_CACHE_ALWAYS option takes nearly 2 hours more than before
(from ~ 5h40 to 7h30).

It's probably due to the RANDOMIZE_ALLOCATED_MEMORY overhead added here:

pgsql/src/backend/utils/mmgr/aset.c 1.77

Right now that's on by default in assert-enabled builds. I'm not
sure if we want to leave it like that for long ...

regards, tom lane

On Sun, Apr 20, 2008 at 6:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

It's probably due to the RANDOMIZE_ALLOCATED_MEMORY overhead added here:

pgsql/src/backend/utils/mmgr/aset.c 1.77

Right now that's on by default in assert-enabled builds. I'm not
sure if we want to leave it like that for long ...

OK. It's not a problem by itself. I just wanted to point it out.

Thanks.

--
Guillaume