From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Memory leak in FDW |
Date: | 2011-04-26 19:45:25 |
Message-ID: | BANLkTinT=g8n467apNRquXQ==Js2iaETcQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 26, 2011 at 7:15 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Excerpts from Heikki Linnakangas's message of mar abr 26 15:06:51 -0300 2011:
>
>> I tried to look around for other executor nodes that might
>> have the same problem. I didn't see any obvious leaks, although index
>> scan node seems to call AM's getnext without resetting the memory
>> context in between. That's a pretty well-tested codepath, however, and
>> there hasn't been any complains of leaks with index scans, so there must
>> be something that mitigates it.
>
> Don't we have some rule that functions used in index AMs are supposed to
> be leak-free?
btree operators and opclass functions are supposed to be leak-free. I
think other AMs don't try to have the same strictness.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2011-04-26 19:49:31 | Re: 2nd Level Buffer Cache |
Previous Message | Markus Wanner | 2011-04-26 19:32:57 | Re: Proposal - asynchronous functions |