[postgis-devel] [PostGIS] #851: [raster] Numerous ST_Value query cause the memory to grow indefinitely

PostGIS trac at osgeo.org
Tue Apr 26 09:18:19 PDT 2011


#851: [raster] Numerous ST_Value query cause the memory to grow indefinitely
----------------------------+-----------------------------------------------
 Reporter:  pracine         |       Owner:  jorgearevalo 
     Type:  defect          |      Status:  assigned     
 Priority:  blocker         |   Milestone:  PostGIS 2.0.0
Component:  postgis raster  |     Version:  trunk        
 Keywords:                  |  
----------------------------+-----------------------------------------------

Comment(by jorgearevalo):

 Understood. The main problem I saw is that every time a raster core
 function is called (for example, rt_band_get_pixel) a new chunk of memory
 for rt_context is allocated.

 This memory is allocated in fcinfo->flinfo->fn_mcxt memory context, a
 postgres memory context that has query lifespan, and could be even longer
 lived than that. So, this memory allocated for rt_context must be always
 released, to avoid memory leaks in cases of losing control because any
 postgres function throws a elog(ERROR).

 So, following Tom Lane's advices, I think most of the raster core
 functions should work in function calling memory context, not in
 fcinfo->flinfo->fn_mcxt. The only exception so far is
 rt_dump_as_wktpolygons function, that needs to store some data to live
 between function calls. For that reason, it uses multi_call_memory_ctx,
 the recommended context for this kind of functions (SRF).

 Apart from this problem, using a struct to keep pointers to all memory
 functions together (like rt_context) instead of using single vars (like
 PostGIS does) is not a big deal. But I think a static rt_context var would
 be less harmful, in terms of memory consumption.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/851#comment:35>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.


More information about the postgis-devel mailing list