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

On 24.8.2014 18:28, Tom Lane wrote:
> Tomas Vondra <tv(at)fuzzy(dot)cz> writes:
>> Regarding those leaks we've detected so far - is it the kind of leaks
>> that can happen only in testing with those specific flags, or is it
>> something that can happen in production too? (Assuming no one is running
>> with CLOBBER_CACHE_RECURSIVELY in production, of course ;-) That is,
>> does it seem worth the effort running those tests / fixing those leaks?
>
> I believe most or all of these leaks were understood and intentionally
> ignored in the original coding, on the grounds that they were intraquery
> leaks and no real-world situation would ever cause so many cache reloads
> in a single query that the leakage would amount to anything problematic.
> I think that reasoning is still valid for production usage. It seems
> worth fixing the leaks in HEAD so that we can get through the regression
> tests on barnacle and see if anything of greater significance turns up ---
> but if this is all we find, it might not have been worth the trouble.

OK. Some time ago we got a report (on the czech mailing list) with this:

TopMemoryContext: 1375320 total in 168 blocks; 6472 free (18 chunks);
1368848 used
...
CacheMemoryContext: 232883248 total in 5251 blocks; 5644000 free (2
chunks); 227239248 used

Apparently they're using some sort of persistent connections, and
there's ~8000 tables in that particular database, which eventually leads
to OOM for them. Could this be related?

Anyway, let's leave the tests running - either we find something
interesting or not. I think it's worth it.

regards
Tomas