server crash on recursive function invocation
hi,
i was just trying recursive function invocation and got a server crash when i changed a GUC variable max_stack_depth, to a high number.
fallowing is what i have tried.
select max_val from pg_settings where name='max_stack_depth'; -- returns 2097151
set max_stack_depth=2097151;
CREATE OR REPLACE FUNCTION func() RETURNS INT AS $$
DECLARE
x int;
BEGIN
null;
x := func();
return 0;
END;
$$ LANGUAGE PLPGSQL;
select func();
and the server get crashed.
Any ideas?
Thanks,
--Usman
---------------------------------
Be a chatter box. Enjoy free PC-to-PC calls with Yahoo! Messenger with Voice.
Ali Baba said:
hi,
i was just trying recursive function invocation and got a server crash
when i changed a GUC variable max_stack_depth, to a high number.
fallowing is what i have tried.select max_val from pg_settings where name='max_stack_depth'; --
returns 2097151 set max_stack_depth=2097151;
CREATE OR REPLACE FUNCTION func() RETURNS INT AS $$
DECLARE
x int;
BEGIN
null;
x := func();
return 0;
END;
$$ LANGUAGE PLPGSQL;
select func();
and the server get crashed.Any ideas?
what the heck did you expect with an infinitely recursive function?
cheers
andrew
Ali Baba <idofyear@yahoo.com> writes:
i was just trying recursive function invocation and got a server crash when i changed a GUC variable max_stack_depth, to a high number.
There's a reason why that variable is a superuser-only setting: you're
supposed to have some clue what you're doing when you change it ;-)
If you need more stack space, what you generally have to do is adjust
the ulimit setting that the postmaster is started under. You can set
max_stack_depth up to a few hundred K less than the postmaster's
ulimit -s setting, but not more.
(We wouldn't even have the variable if there were a sufficiently
portable way to find out the ulimit stack depth automatically, but
there's not one that I know of.)
regards, tom lane