Re: Partitioning option for COPY

From: Emmanuel Cecchet <manu(at)asterdata(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jan Urbański <wulczer(at)wulczer(dot)org>, Emmanuel Cecchet <manu(at)asterdata(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Partitioning option for COPY
Date: 2009-11-17 14:59:58
Message-ID: 4B02BA6E.4060303@asterdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <wulczer(at)wulczer(dot)org> writes:
>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0819368b in route_tuple_to_child (parent_relation=0xb5d93040,
>> tuple=0x873b08c, hi_options=0, parentResultRelInfo=0x871e204) at copy.c:1821
>> 1821 child_relation_id =
>> child_oid_cell->oid_value;
>> (gdb) p child_oid_cell
>> $1 = (OidCell *) 0x7f7f7f7f
>>
>
> 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?

Thanks
Emmanuel

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-11-17 15:03:39 Re: Partitioning option for COPY
Previous Message Tom Lane 2009-11-17 14:55:07 Re: Raising the geqo_threshold default