2011/3/23 Pavel Stehule <pavel.stehule@xxxxxxxxx>: > 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.arevalo@xxxxxxxxxxxxxxxx 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.arevalo@xxxxxxxxxxxxxxxx>: >> 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@xxxxxxxxxxxxxx/msg79320.html >> >> Thanks in advance, >> >> -- >> Jorge Arévalo >> Internet & Mobilty Division, DEIMOS >> jorge.arevalo@xxxxxxxxxxxxxxxx >> 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@xxxxxxxxxxxxxx) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-general >> > -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
