From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: unchecked out of memory in postmaster.c |
Date: | 2009-04-06 23:20:39 |
Message-ID: | 20090406232039.GM4525@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Some time ago I noticed that in postmaster.c there's a corner case which
> > probably causes postmaster to exit in out-of-memory condition. See
> > BackendStartup, near the bottom, there's a call to DLNewElem(). The
> > problem is that this function calls palloc() and thus can elog(ERROR) on
> > OOM, but postmaster has no way to defend itself from this and would die.
>
> So? There are probably hundreds of palloc calls that are reachable from
> the postmaster main loop. If this were allocating more than a few bytes
> of memory, it might be worth worrying about.
Hundreds? I think you'd be hard pressed to find as much as a dozen :-)
I mean stuff that's called inside ServerLoop, of course. There are a
few places calling alloc-type functions, but as far as I see they use
calloc or malloc, and behave "sanely" (i.e. not elog(ERROR)) in OOM.
Note that BackendStartup itself is very careful about allocating a
Backend struct, even when it's just ~10 bytes on 32 bits machines.
I think a patch to solve this is as simple as the attached.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Attachment | Content-Type | Size |
---|---|---|
oom.patch | text/x-diff | 1.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-04-06 23:24:16 | default parameters for built-in functions (was Re: Documentation Update: Document pg_start_backup checkpoint behavior) |
Previous Message | Tom Lane | 2009-04-06 23:07:35 | Re: unchecked out of memory in postmaster.c |