I've come up with a simpler test case:
CREATE OR REPLACE FUNCTION foo(INTEGER) RETURNS INTEGER AS $$
my @a = 1..$_[0];
elog INFO, "array has $_[0] elements";
return $_[0];
$$ LANGUAGE plperl;
Here's the Solaris 9 failure mode:
test=> select foo(131); -- works consistently
INFO: array has 131 elements
foo
-----
131
(1 row)
test=> select foo(132); -- fails consistently
INFO: array has 132 elements
server closed the connection unexpectedly
This test also fails on FreeBSD 4.10, but at a higher resource usage
than on Solaris:
test=> select foo(260); -- works consistently
INFO: array has 260 elements
foo
-----
260
(1 row)
test=> select foo(261); -- fails consistently
INFO: array has 261 elements
server closed the connection unexpectedly
It looks like some resource is being exhausted that has a higher
setting on my FreeBSD box than on my Solaris box. Interestingly,
the elog output shows that the crash doesn't happen until the
function returns. Here's the gdb output from Solaris:
% sudo -u postgres gdb /usr/local/pgsql/bin/postgres
...
(gdb) run -D/usr/local/pgsql/data test
...
PostgreSQL stand-alone backend 8.0.0beta4
backend> select foo(132);
1: foo (typeid = 23, len = 4, typmod = -1, byval = t)
----
Program received signal SIGSEGV, Segmentation fault.
0xfecc3378 in Perl_pop_return () from /usr/local/lib/libperl.so
(gdb) bt
#0 0xfecc3378 in Perl_pop_return () from /usr/local/lib/libperl.so
#1 0xfec295f8 in Perl_call_sv () from /usr/local/lib/libperl.so
#2 0xfeda413c in plperl_call_perl_func (desc=0xffbff178, fcinfo=0x0) at
plperl.c:810
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
