Re: [BUG] Segmentation fault in pfree in PLy_output_tuple_funcs
От | Sergey Konoplev |
---|---|
Тема | Re: [BUG] Segmentation fault in pfree in PLy_output_tuple_funcs |
Дата | |
Msg-id | CAL_0b1vyL_MNdQ1LZKE6+yt8h8e-mS0tMUugxturB3CYLN4mrA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUG] Segmentation fault in pfree in PLy_output_tuple_funcs (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUG] Segmentation fault in pfree in PLy_output_tuple_funcs
|
Список | 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 по дате отправления: