Re: failures on barnacle (CLOBBER_CACHE_RECURSIVELY) because of memory leaks

From: Tomas Vondra <tv(at)fuzzy(dot)cz>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: failures on barnacle (CLOBBER_CACHE_RECURSIVELY) because of memory leaks
Date: 2014-08-13 17:17:11
Message-ID: 53EB9D97.5080201@fuzzy.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 13.8.2014 17:52, Tom Lane wrote:
> "Tomas Vondra" <tv(at)fuzzy(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Claudio Freire 2014-08-13 17:33:39 Re: Proposal: Incremental Backup
Previous Message Heikki Linnakangas 2014-08-13 17:05:58 Re: WAL format and API changes (9.5)