On Wed, Aug 06, 2003 at 04:47:42PM -0400, Rudy Lippan wrote:
> > In dbdimp.c:dbd_discon_all is this code:
> >
> > if (perl_destruct_level) {
> > perl_destruct_level =3D 0;
> > }
> >
> > It looks like this is because it doesn't support being told to clean up.
> >
> > Resetting perl_destruct_level is absolutely wrong; this is the cause of
> > the 3MB or more memory leaked every time you SIGHUP a mod_perl server
> > using DBD::Pg. Removing this code fixes the problem but I don't know
> > what affect it'll have on DBD::Pg; I didn't see any adverse effects but
> > I didn't test it very well.
> >
> > Does anyone know why this reset is there? Can it be removed from the sources?
> > It's not in DBD::Oracle certainly since 1.06 dated 2000/07.
>
> Since dbd_discon_all() is the same between DBD::mysql & DBD::Pg, I am
> going to assume that this bit of code was inhereted from an old version of
> DBD::Oracle. I don't see anything in the DBD::Oracle docs about
> perl_destruct_level, so I don't know (if or when) it was removed from
> DBD::Oracle; however, I did see ' No longer sets perl_destruct_level
> unless debug set >= 4.' in the DBI Changelog, so maybe that was in there
> to work with dbi chaing destruct levels???
I can't remember the details now. But there's certainly no good reason
for a driver to ever _lower_ the value of perl_destruct_level.
> Given that dbd_discon_all is just about the same in DBD::Pg, DBD::mysql
> DBD::Oracle, should/could it be brought into driver.xst?
It already is to some extent. And note that disconnect_all is not
a documented part of the DBI spec so the current "set error if
called explicitly" behaviour isn't mandated anywhere.
All you need to do is stop #defining dbd_discon_all then the
DBI's default disconnect_all method will be called instead,
which does... nothing.
Tim.
