Обсуждение: In what cases can SPI_finish crash postgres backend?
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
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 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 >
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 >> >