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@postgresql.org/msg79320.html
Thanks in advance,
--
Jorge Arévalo
Internet & Mobilty Division, DEIMOS
jorge.arevalo@deimos-space.com
http://es.linkedin.com/in/jorgearevalo80
http://mobility.grupodeimos.com/
http://gis4free.wordpress.com
http://geohash.org/ezjqgrgzz0g
