Re: In what cases can SPI_finish crash postgres backend?
От | Jorge Arévalo |
---|---|
Тема | Re: In what cases can SPI_finish crash postgres backend? |
Дата | |
Msg-id | AANLkTik=9FAiByx6twGt-woPDbdE1Fd=Shw7XXTdgv7o@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: In what cases can SPI_finish crash postgres backend? (Pavel Stehule <pavel.stehule@gmail.com>) |
Список | pgsql-general |
2011/3/23 Pavel Stehule <pavel.stehule@gmail.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.arevalo@deimos-space.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.arevalo@deimos-space.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@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 >> >> -- >> Sent via pgsql-general mailing list (pgsql-general@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-general >> >
В списке pgsql-general по дате отправления: