Re: Partitioning option for COPY

Emmanuel Cecchet <manu@asterdata.com>

From: Emmanuel Cecchet <manu@asterdata.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Emmanuel Cecchet <Emmanuel.Cecchet@asterdata.com>, Jan Urbański <wulczer@wulczer.org>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2009-11-17T15:31:11Z
Lists: pgsql-hackers
Tom Lane wrote:
> Emmanuel Cecchet <manu@asterdata.com> writes:
>   
>> Tom Lane wrote:
>>     
>>> This looks like the patch is trying to create a data structure in a
>>> memory context that's not sufficiently long-lived for the use of the
>>> structure.  If you do this in a non-cassert build, it will seem to
>>> work, some of the time, if the memory in question happens to not
>>> get reallocated to something else.
>>>
>>>       
>> I was using the CacheMemoryContext. Could someone tell me why this is 
>> wrong and what should have been the appropriate context to use?
>>     
>
> Well, (a) I doubt you really were creating the list in
> CacheMemoryContext, else it'd have not gotten clobbered; (b) creating
> statement-local data structures in CacheMemoryContext is entirely
> unacceptable anyway, because then they represent a permanent memory
> leak.
>   
Well I thought that this code would do it:

 					child_table_lru = (OidLinkedList *)MemoryContextAlloc(
+ 						CacheMemoryContext, sizeof(OidLinkedList));
...
+ 				/* Add the new entry in head of the list */
+ 				new_head = (OidCell *) MemoryContextAlloc(
+ 					CacheMemoryContext, sizeof(OidCell));


> The right context for statement-lifetime data structures is generally
> the CurrentMemoryContext the statement code is called with.
>   
Actually the list is supposed to stay around between statement 
executions. You don't want to restart with a cold cache at every 
statement so I really want this structure to stay in memory at a more 
global level.

Emmanuel

-- 
Emmanuel Cecchet
Aster Data
Web: http://www.asterdata.com