From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Marko Tiikkaja <pgmail(at)joh(dot)to> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #7516: PL/Perl crash |
Date: | 2012-09-09 22:37:58 |
Message-ID: | 17785.1347230278@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
I wrote:
> Hm. Well, I can definitely reproduce a segfault using this example:
> CREATE OR REPLACE FUNCTION self_modify(INTEGER) RETURNS INTEGER AS $$
> spi_exec_query('CREATE OR REPLACE FUNCTION self_modify(INTEGER) RETURNS INTEGER AS \'return $_[0] * 3;\' LANGUAGE plperl;');
> spi_exec_query('select self_modify(42) AS a');
> return $_[0] * 2;
> $$ LANGUAGE plperl;
> select self_modify(42);
> So I think we need to institute a reference counting scheme for
> the plperl_proc_desc records ...
The attached patch fixes the problem I'm seeing. I am not sure whether
it fixes what you saw; the crash you showed is in the right place, but
unless there was a recursive call to a pl/perl function, I don't see
how the existing code could have freed the prodesc too soon.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
plperl-use-refcounts.patch | text/x-patch | 14.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Kirkwood | 2012-09-10 01:04:41 | Re: BUG #7524: Partitioning |
Previous Message | Tom Lane | 2012-09-09 21:32:00 | Re: BUG #7516: PL/Perl crash |