Autovacuum worker does not set stack_base_ptr

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Cc: Johann 'Myrkraverk' Oskarsson <johann@2ndquadrant.com>
Date: 2012-04-01T16:31:46Z
Lists: pgsql-hackers

Attachments

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