Autovacuum worker does not set stack_base_ptr
От | Heikki Linnakangas |
---|---|
Тема | Autovacuum worker does not set stack_base_ptr |
Дата | |
Msg-id | 4F7882F2.1010402@enterprisedb.com обсуждение исходный текст |
Ответы |
Re: Autovacuum worker does not set stack_base_ptr
|
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: