Re: [BUGS] [CHECKER] 4 memory leaks in Postgresql 7.4.2 - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [BUGS] [CHECKER] 4 memory leaks in Postgresql 7.4.2
Date
Msg-id 200407052113.i65LDNK21463@candle.pha.pa.us
Whole thread Raw
In response to Re: [BUGS] [CHECKER] 4 memory leaks in Postgresql 7.4.2  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Responses Re: [BUGS] [CHECKER] 4 memory leaks in Postgresql 7.4.2  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
List 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@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: plperl security
Next
From: "Jeroen T. Vermeulen"
Date:
Subject: Re: subtransactions and FETCH behaviour (was Re: PREPARE and transactions)