Re: failures on barnacle (CLOBBER_CACHE_RECURSIVELY) because of memory leaks - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: failures on barnacle (CLOBBER_CACHE_RECURSIVELY) because of memory leaks
Date
Msg-id 53EB9D97.5080201@fuzzy.cz
Whole thread Raw
In response to Re: failures on barnacle (CLOBBER_CACHE_RECURSIVELY) because of memory leaks  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: failures on barnacle (CLOBBER_CACHE_RECURSIVELY) because of memory leaks
List pgsql-hackers
On 13.8.2014 17:52, Tom Lane wrote:
> "Tomas Vondra" <tv@fuzzy.cz> writes:
>> So after 83 days, the regression tests on barnacle completed, and it
>> smells like another memory leak in CacheMemoryContext, similar to those
>> fixed in 078b2ed on May 18.
> 
> I've pushed fixes for the issues I was able to identify by running the
> create_view test.  I definitely don't have the patience to run all the
> tests this way, but if you do, please start a new run.
> 
> A couple thoughts about barnacle's configuration:
> 
> * It's not necessary to set -DCLOBBER_FREED_MEMORY or -DMEMORY_CONTEXT_CHECKING
> in CPPFLAGS; those are already selected by --enable-cassert.  Removing
> those -D switches would suppress a whole boatload of compiler warnings.

I know - I already fixed this two months ago, but barnacle was still
running with the old settings (and I decided to let it run).

> * I'm a bit dubious about testing -DRANDOMIZE_ALLOCATED_MEMORY in the
> same build as -DCLOBBER_CACHE_RECURSIVELY, because each of these is
> darned expensive and it's not clear you'd learn anything by running
> them both together.  I think you might be better advised to run two
> separate buildfarm critters with those two options, and thereby perhaps
> get turnaround in something less than 80 days.

OK, I removed this for barnacle/addax/mite, let's see what's the impact.

FWIW We have three other animals running with CLOBBER_CACHE_ALWAYS +
RANDOMIZE_ALLOCATED_MEMORY, and it takes ~20h per branch. But maybe the
price when combined with CLOBBER_CACHE_RECURSIVELY is much higher.

> * It'd likely be a good idea to take out the TestUpgrade and TestDecoding
> modules from the config too.  Otherwise, we won't be seeing barnacle's
> next report before 2015, judging from the runtime of the check step
> compared to some of the other slow buildfarm machines.  (I wonder whether
> there's an easy way to skip the installcheck step, as that's going to
> require a much longer run than it can possibly be worth too.)

OK, I did this too.

I stopped the already running test on addax and started the test on
barnacle again. Let's see in a few days/weeks/months what is the result.

regards
Tomas



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: WAL format and API changes (9.5)
Next
From: Claudio Freire
Date:
Subject: Re: Proposal: Incremental Backup