| 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-07 02:31:11 |
| Message-ID: | 20090407023111.GQ4525@alvh.no-ip.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Tom Lane wrote:
> >> I guess I need to point out that those ereport calls already pose a far
> >> more substantial risk of palloc failure than the DLNewElem represents.
>
> > Hmm, do they? I mean, don't they use ErrorContext, which is supposed to
> > be preallocated?
>
> Well, we'd like to think that they pose an insignificant risk, but it's
> hard to credit that DLNewElem isn't insignificant as well.
Yeah, actually as I said earlier, I haven't ever seen this.
> If you're really intent on doing something about this, my inclination
> would be to get rid of the dependence on DLNewElem altogether. Add
> a Dlelem field to the Backend struct and use DLInitElem (compare
> the way catcache uses that module).
Hmm, yeah, I had seen that code. So it looks like this instead.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
| Attachment | Content-Type | Size |
|---|---|---|
| oom-2.patch | text/x-diff | 1.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-04-07 02:36:26 | Re: more on out-of-memory |
| Previous Message | Alvaro Herrera | 2009-04-07 02:16:04 | more on out-of-memory |