Thread: Properly initialize negative/empty cache entries in relfilenodemap
Hi, Thanks to the valgrind instrumentation I found a small oversight in the relfilenodemap patch which is fixed in the attached patch. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Attachment
Andres Freund wrote: > Hi, > > Thanks to the valgrind instrumentation I found a small oversight in the > relfilenodemap patch which is fixed in the attached patch. Pushed, thanks. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
> Andres Freund wrote: >> Hi, >> >> Thanks to the valgrind instrumentation I found a small oversight in the >> relfilenodemap patch which is fixed in the attached patch. Great! Could anybody find the root cause for the following memory leak problem, and if possible, fix this? http://www.postgresql.org/message-id/214653D8DF574BFEAA6ED53E545E99E4@maumau Heiki helped to solve this and found that pg_statistic entries are left in CacheMemoryContext, but we have no idea where and how they are created and left. This seems difficult to me. Regards MauMau
On 2013-08-29 21:35:13 +0900, MauMau wrote: > >Andres Freund wrote: > >>Hi, > >> > >>Thanks to the valgrind instrumentation I found a small oversight in the > >>relfilenodemap patch which is fixed in the attached patch. > Great! Could anybody find the root cause for the following memory leak > problem, and if possible, fix this? > http://www.postgresql.org/message-id/214653D8DF574BFEAA6ED53E545E99E4@maumau > Heiki helped to solve this and found that pg_statistic entries are left in > CacheMemoryContext, but we have no idea where and how they are created and > left. This seems difficult to me. That doesn't have anything to do with this patch/feature though, has it? For one, the feature has only been integrated into HEAD after you've reported the issue, for another, it's not even active unless you use it the first time. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
Hi,
On Thu, Aug 29, 2013 at 2:35 PM, MauMau <maumau307@gmail.com> wrote:
- if there's no row in pg_statistic for a relation/column then RemoveStatistics, called by DROP ..., doesn't invalidate the cache (which should remove these negative entries).
Great! Could anybody find the root cause for the following memory leak problem, and if possible, fix this?
http://www.postgresql.org/message-id/214653D8DF574BFEAA6ED53E545E99E4@maumau
Heiki helped to solve this and found that pg_statistic entries are left in CacheMemoryContext, but we have no idea where and how they are created and left. This seems difficult to me.
VALGRIND won't help you for this one
You hit 2 issues
- user can create negative cache entries in pg_statistic with SELECT but they are unbound (at first there was a LRU aging but it was removed in 2006)
- if there's no row in pg_statistic for a relation/column then RemoveStatistics, called by DROP ..., doesn't invalidate the cache (which should remove these negative entries).