Обсуждение: Re: [BUGS] [CHECKER] 4 memory leaks in Postgresql 7.4.2
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. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) Dios hizo a Adán, pero fue Eva quien lo hizo hombre.
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
On Mon, Jul 05, 2004 at 05:13:23PM -0400, Bruce Momjian wrote: > 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. Yes, I understand that part -- what I was talking about was not using the code in the Pg interfaces, but in another software project which also consists of a daemon that has several well defined "durations" of objects. In that (as of yet unwritten) code, palloc would fit very well. But does palloc depend on some other part of the Postgres code? -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "El Maquinismo fue proscrito so pena de cosquilleo hasta la muerte" (Ijon Tichy en Viajes, Stanislaw Lem)
Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> 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.
It's useless without the rest of the backend infrastructure, including
elog error recovery and a cooperative main loop. You could certainly
reuse the code in a different application if you were willing to adopt
Postgres' memory management and error handling approaches
lock-stock-and-barrel, but I don't think you could be selective about
it. For a library that has to work inside a not-so-cooperative
application, the idea is a nonstarter.
regards, tom lane
Alvaro Herrera wrote: > On Mon, Jul 05, 2004 at 05:13:23PM -0400, Bruce Momjian wrote: > >>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. > > > Yes, I understand that part -- what I was talking about was not using > the code in the Pg interfaces, but in another software project which > also consists of a daemon that has several well defined "durations" of > objects. In that (as of yet unwritten) code, palloc would fit very > well. But does palloc depend on some other part of the Postgres code? > If you don't mind you can write your application in C++ and use a boost smartpointer: http://www.boost.org/libs/smart_ptr/smart_ptr.htm Regards Gaetano Mendola