Marko Tiikkaja <pgm...@joh.to> writes:
> On 03/09/2012 18:06, Tom Lane wrote:
>> Hm. Is it possible that the prepared statement recursively called the
>> *same* plperl function? And that somebody did a CREATE OR REPLACE on
>> that function meanwhile?
> No, that doesn't seem possible in this case. The function calls some
> prepared statements repeatedly, but no recursion should occur.
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);
The crash is 100% reproducible if you tweak plperl like this:
diff --git a/src/pl/plperl/plperl.c b/src/pl/plperl/plperl.c
index bfa805d..307874c 100644
--- a/src/pl/plperl/plperl.c
+++ b/src/pl/plperl/plperl.c
@@ -2393,7 +2393,7 @@ validate_plperl_function(plperl_proc_ptr *proc_ptr, HeapTu
activate_interpreter(oldinterp);
}
free(prodesc->proname);
- free(prodesc);
+ memset(prodesc, 0, sizeof(plperl_proc_desc));
}
return false;
Without that it's probabilistic, since the subsequent malloc in
compile_plperl_function is likely to realloc the exact same space.
So I think we need to institute a reference counting scheme for
the plperl_proc_desc records ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
