Currently, only regular backends set the stack base pointer, for the
check_stack_depth() mechanism, in PostgresMain. We don't have stack
overrun protection in auxiliary processes. However, autovacuum workers
at least can run arbitrary user code, and if that overruns the stack,
you get a segfault.
Here's a little script to reproduce that:
begin;
create table atable(id int4);
insert into atable select generate_series(1,10000);
/* not recursive yet */
create or replace function recfunc(i int4) returns bool AS $$begin
return true;
end;
$$ language plpgsql immutable;
/* Create index using the function. */
create index recindex on atable((recfunc(id)));
/* make the function recursive */
create or replace function recfunc(i int4) returns bool AS $$begin
perform recfunc(i);
end;
$$ language plpgsql immutable;
commit;
/* Now wait for autoanalyze to kick in, and crash */
The fix is quite straightforward, we just need to set the stack base
pointer. I think we should set it in all processes, even though most
auxiliary processes like bgwriter can't execute arbitrary code. There's
no harm in doing so, anyway. I'm thinking that we should set the base
pointer in PostmasterMain(), so that it is inherited by all forked
processes, and in SubPostmasterMain() for EXEC_BACKEND.
Proposed patch attached. The comment changes regarding PL/Java are in
anticipation for a fix for the Itanium-issue mentioned here:
http://lists.pgfoundry.org/pipermail/pljava-dev/2012/001906.html.
Nothing has yet been done in PL/Java, but I am assuming it will start
using the set/restore_stack_base() functions introduced in this patch.
However, we might need to do something more complicated to fix the first
PL/Java issue I explain in that email.
I suppose this needs to be backpatched all the way to 8.3.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
