| 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: | Whole Thread | Raw Message | 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 |