From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Jorge Arévalo <jorge(dot)arevalo(at)deimos-space(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: In what cases can SPI_finish crash postgres backend? |
Date: | 2011-03-23 18:28:13 |
Message-ID: | AANLkTi=VbvG0a6XtVvGBF=YscKYipedk_WiE9UNA4Hjg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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(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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jorge Arévalo | 2011-03-23 18:31:54 | Re: In what cases can SPI_finish crash postgres backend? |
Previous Message | Radosław Smogura | 2011-03-23 18:10:31 | Re: Understanding Datum |