On 24.8.2014 18:28, Tom Lane wrote: > Tomas Vondra <t...@fuzzy.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
