From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
Cc: | Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [BUGS] [CHECKER] 4 memory leaks in Postgresql 7.4.2 |
Date: | 2004-07-05 21:13:23 |
Message-ID: | 200407052113.i65LDNK21463@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Alvaro Herrera wrote:
> On Sun, May 02, 2004 at 07:50:46PM -0400, Tom Lane wrote:
>
> > It's entirely likely that ecpg's derivative of the backend's datetime
> > modules contains lots and lots of memory leaks, since AFAIK the palloc
> > infrastructure is not there in the ecpg environment :-(.
>
> I wonder why is this? Is there some limitation to using palloc outside
> the backend itself? I ask because I have considered using it outside
> Postgres several times (a consideration that has never materialized
> yet), and I wonder if it needs something special to work.
The semantics of palloc is that most stuff is freed on statement
completion. In most cases, interfaces need different semantics so we
haven't seen much need for making something like palloc available to
clients. I can see ecpg using it in a few cases, and libpq too, but
probably not enough to make it worthwhile.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2004-07-05 21:30:21 | Re: [BUGS] [CHECKER] 4 memory leaks in Postgresql 7.4.2 |
Previous Message | Alvaro Herrera | 2004-07-05 20:23:28 | Re: [BUGS] [CHECKER] 4 memory leaks in Postgresql 7.4.2 |
From | Date | Subject | |
---|---|---|---|
Next Message | Jeroen T. Vermeulen | 2004-07-05 21:17:27 | Re: subtransactions and FETCH behaviour (was Re: PREPARE and transactions) |
Previous Message | Andrew Dunstan | 2004-07-05 20:58:08 | Re: plperl security |