On lör, 2012-04-28 at 00:32 -0400, Tom Lane wrote:
> I'm inclined to think that the best fix is for
> PLy_spi_execute_fetch_result to copy the tupledesc into
> TopMemoryContext, not the current context. This is a tad scary from a
> memory leakage standpoint, but I suppose that if python fails to r
Peter Eisentraut writes:
> On tor, 2012-04-26 at 17:32 +0500, Asif Naeem wrote:
>> PFA test case. It used simple select statement to retrieve data via
>> plpython. It crashes latest pg 9.2 with the following stack trace i.e.
>> Apparently it is being crashed because of invalid related pointer val
Peter Eisentraut writes:
> I must have been confused about the tuple descriptor APIs. ob->tupdesc
> is created using CreateTupleDescCopy(), which copies the refcount of the
> original tuple descriptor,
Um, surely not. That would be nonsensical, and anyway a look at the
code shows it isn't doing
On tor, 2012-04-26 at 17:32 +0500, Asif Naeem wrote:
> PFA test case. It used simple select statement to retrieve data via
> plpython. It crashes latest pg 9.2 with the following stack trace i.e.
> Apparently it is being crashed because of invalid related pointer value of
> pfree() *header->contex
FYI,
I have observed this crash on Linux64. Thanks.
Best Regards,
Muhammad Asif Naeem
On Thu, Apr 26, 2012 at 5:32 PM, Asif Naeem wrote:
> Hi,
>
> PFA test case. It used simple select statement to retrieve data via
> plpython. It crashes latest pg 9.2 with the following stack trace i.e.
>
> #0
Hi,
PFA test case. It used simple select statement to retrieve data via
plpython. It crashes latest pg 9.2 with the following stack trace i.e.
#0 0x0073021f in pfree ()
> #1 0x7fa74b632f7a in PLy_result_dealloc () from
> /home/masif/work/postgresql/postgresql/inst/lib/plpython2.so
>
On 17/08/11 23:10, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> Here are two patches that fix two separate bugs that you found
>> simultaneously. Because they're actually separate issues, it turned out
>> fixing them was a bit more tricky than I expected (fixing one was
>> unmaski
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> Here are two patches that fix two separate bugs that you found
> simultaneously. Because they're actually separate issues, it turned out
> fixing them was a bit more tricky than I expected (fixing one was
> unmasking the other one etc).
Applied with one
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> On 16/08/11 19:07, Jean-Baptiste Quenot wrote:
>>> [plpython is buggy]
> Here are two patches that fix two separate bugs that you found
> simultaneously. Because they're actually separate issues, it turned out
> fixing them was a bit more tricky than I
On 17/08/11 11:40, Jan Urbański wrote:
> On 16/08/11 19:12, Jan Urbański wrote:
>> On 16/08/11 19:07, Jean-Baptiste Quenot wrote:
>>>
>>> [plpython is buggy]
> I'll have a patch ready soon.
Here are two patches that fix two separate bugs that you found
simultaneously. Because they're actually sep
On 16/08/11 19:12, Jan Urbański wrote:
> On 16/08/11 19:07, Jean-Baptiste Quenot wrote:
>> Dear Jan,
>>
>> Sorry I typed the wrong git commands. With latest plpython from
>> branch master I got the same gdb backtrace as reported before. I
>> managed to wrap up a testcase that fails 100% of times
On 16/08/11 19:07, Jean-Baptiste Quenot wrote:
> Dear Jan,
>
> Sorry I typed the wrong git commands. With latest plpython from
> branch master I got the same gdb backtrace as reported before. I
> managed to wrap up a testcase that fails 100% of times on my setup:
> https://gist.github.com/114951
Dear Jan,
Sorry I typed the wrong git commands. With latest plpython from
branch master I got the same gdb backtrace as reported before. I
managed to wrap up a testcase that fails 100% of times on my setup:
https://gist.github.com/1149512
Hope it crashes on your side too :-)
This is the result
On 16/08/11 17:06, Jan Urbański wrote:
> On 16/08/11 16:52, Jean-Baptiste Quenot wrote:
>> After backporting plpython.c from HEAD, this is the error message I get:
>>
>> ERROR: key "pg.dropped.6" not found in mapping
>> HINT: To return null in a column, add the value None to the m
On 16/08/11 16:52, Jean-Baptiste Quenot wrote:
> After backporting plpython.c from HEAD, this is the error message I get:
>
> ERROR: key "pg.dropped.6" not found in mapping
> HINT: To return null in a column, add the value None to the mapping
> with the key named after the column
After backporting plpython.c from HEAD, this is the error message I get:
ERROR: key "pg.dropped.6" not found in mapping
HINT: To return null in a column, add the value None to the mapping
with the key named after the column.
CONTEXT: while creating return value
PL/Python functio
On 12/08/11 13:55, Jean-Baptiste Quenot wrote:
> Here is the same with -O0:
>
> https://gist.github.com/1140005
>
> sys.version reports this:
>
> INFO: 2.6.6 (r266:84292, Sep 15 2010, 16:41:53)
> [GCC 4.4.5]
I'm still at a loss. Did you reproduce it with git HEAD? I see that the
query being ex
Here is the same with -O0:
https://gist.github.com/1140005
sys.version reports this:
INFO: 2.6.6 (r266:84292, Sep 15 2010, 16:41:53)
[GCC 4.4.5]
--
Jean-Baptiste Quenot
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
On 11/08/11 18:01, Jean-Baptiste Quenot wrote:
> Hi there,
>
> plpython crashes on me on various 64-bit Ubuntu hosts, see the gdb
> backtrace at: https://gist.github.com/1140005
>
> Do you believe there was recent bugfixes regarding PLyMapping_ToTuple() ?
>
> This is PG 9.0.4 with HEAD of plpyth
Hi there,
plpython crashes on me on various 64-bit Ubuntu hosts, see the gdb
backtrace at: https://gist.github.com/1140005
Do you believe there was recent bugfixes regarding PLyMapping_ToTuple() ?
This is PG 9.0.4 with HEAD of plpython taken in march 2011 and backported.
Please tell me if you n
20 matches
Mail list logo
