Re: In what cases can SPI_finish crash postgres backend?

2011/3/23 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
> Hello
>
> SPI_finish try to release resources and memory. Maybe you has broken memory.
>
> Try to compile postgres with --enable-debug and --enable-cassert
> flags. You can take more info from core dump.
>
> Regards
>
> Pavel Stehule
>

Hello Pavel,

I'm using a precompiled version of PostgreSQL. I guess I can compile
it myself. Thanks for the advice.
--
Jorge Arévalo
Internet & Mobilty Division, DEIMOS
jorge(dot)arevalo(at)deimos-space(dot)com
http://es.linkedin.com/in/jorgearevalo80
http://mobility.grupodeimos.com/
http://gis4free.wordpress.com
http://geohash.org/ezjqgrgzz0g

> 2011/3/23 Jorge Arévalo <jorge(dot)arevalo(at)deimos-space(dot)com>:
>> Hello,
>>
>> I'm writing my own C-function on server side, to extend SQL. One of my
>> function's arguments is any valid PostgreSQL expression returning a
>> number. Another argument is a specific data type (RASTER type). So, if
>> I execute this function against a table with 1000 rows, each row
>> having one RASTER column, the function does the next for each row:
>>
>> - Connects the function to the SPI manager (SPI_connect)
>> - Executes the expression (SPI_exec)
>> - Gets the result, 1 number (SPI_getvalue)
>> - Uses the result with the data type RASTER (not important)
>> - Frees the memory for the row returned (SPI_freetuptable)
>> - Disconnect the function from SPI manager (SPI_finish)
>>
>> The operations made with the returned result and the RASTER object
>> involve some memory allocations made in fcinfo->flinfo->fn_mcxt memory
>> context, but the memory is explicitly released.
>>
>> The problem is sometimes the function causes a segmentation fault just
>> in the SPI_finish call. I've changed the log system according with
>> http://www.postgresql.org/docs/8.4/static/runtime-config-logging.html,
>> but there's no more information: Segmentation fault caused for a
>> SIGSEV signal.
>>
>> As the crash is caused only with big tables (thousands of rows), I
>> thought in a cumulative memory problem, but I free all the memory
>> allocated out of the function's context, and correct me if I'm wrong,
>> but the memory allocated with palloc in the function's context is
>> automatically freed when it finishes.
>>
>> So, my questions are:
>>
>> - What can be the cause that make SPI_finish to crash by a SIGSEV signal?
>> - What can I do for getting more information about the crash? I
>> thought in attaching gdb to the postgres process (PostgreSQL Server
>> 8.4.6 in Ubuntu Linux machine). Just like this
>> http://www.mail-archive.com/pgsql-general(at)postgresql(dot)org/msg79320.html
>>
>> Thanks in advance,
>>
>> --
>> Jorge Arévalo
>> Internet & Mobilty Division, DEIMOS
>> jorge(dot)arevalo(at)deimos-space(dot)com
>> http://es.linkedin.com/in/jorgearevalo80
>> http://mobility.grupodeimos.com/
>> http://gis4free.wordpress.com
>> http://geohash.org/ezjqgrgzz0g
>>
>> --
>> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>>
>