Re: [BUG] Segmentation fault in pfree in PLy_output_tuple_funcs - Mailing list pgsql-bugs

From Sergey Konoplev
Subject Re: [BUG] Segmentation fault in pfree in PLy_output_tuple_funcs
Date
Msg-id CAL_0b1vyL_MNdQ1LZKE6+yt8h8e-mS0tMUugxturB3CYLN4mrA@mail.gmail.com
Whole thread Raw
In response to Re: [BUG] Segmentation fault in pfree in PLy_output_tuple_funcs  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [BUG] Segmentation fault in pfree in PLy_output_tuple_funcs  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Just want to remind about this issue.

On Tue, Dec 10, 2013 at 2:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Sergey Konoplev <gray.ru@gmail.com> writes:
>> On Tue, Dec 10, 2013 at 1:17 PM, Alvaro Herrera
>> <alvherre@2ndquadrant.com> wrote:
>>> What's the likelihood that table "cars" was being modified concurrently?
>
>> It is rather high. Probably even very high.
>
> This doesn't smell like that's an issue though ...
>
> Just eyeballing the code, I don't see how set-returning plpython functions
> work at all.  Ever.  It looks like they allocate a bunch of stuff in the
> SPI procedure context and expect it to still be there on the next call.
> Why isn't this code falling over in any assert-enabled build?
>
>                         regards, tom lane

^^^

--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA

http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979
gray.ru@gmail.com

pgsql-bugs by date:

Previous
From: Rod Taylor
Date:
Subject: Re: BUG #8681: column 'n_tup_del' of pg_stat_user_tables doesn't change in case of truncate
Next
From: Tom Lane
Date:
Subject: Re: BUG #8681: column 'n_tup_del' of pg_stat_user_tables doesn't change in case of truncate