I'd have to disagree with regards to the memory leaks not being worth
a mention - any such leak can cause problems when the PostgreSQL
installation is either unattended, long-living andor has very high
connection levels. Half a kilobyte on start-up isn't negligible in
this light.
Regards, Lee.
Tom Lane writes:
> Lee Kindness <lkindness@csl.co.uk> writes:
> > Guys, attached is a patch to fix two memory leaks on start-up.
>
> I do not like the changes to miscinit.c. In the first place, it is not
> a "memory leak" to do a one-time allocation of state for a proc_exit
> function. A bigger complaint is that your proposed change introduces
> fragile coupling between CreateLockFile and its callers, in order to
> save no resources worth mentioning. More, it introduces an assumption
> that the globals directoryLockFile and socketLockFile don't change while
> the postmaster is running. UnlinkLockFile should unlink the file that
> it was originally told to unlink, regardless of what happens to those
> globals.
>
> If you are intent on spending code to free stuff just before the
> postmaster exits, a better fix would be for UnlinkLockFile to free its
> string argument after using it.
Lee Kindness
*
*
* IDENTIFICATION
- * $Header: /cvsroot/pgsql/src/backend/utils/init/miscinit.c,v 1.105 2003/07/25 20:17:52 tgl Exp $
+ * $Header: /cvsroot/pgsql/src/backend/utils/init/miscinit.c,v 1.106 2003/07/27 19:39:13 momjian Exp $
*
*-------------------------------------------------------------------------
*/
static void
UnlinkLockFile(int status, Datum filename)
{
- unlink((char *) DatumGetPointer(filename));
- /* Should we complain if the unlink fails? */
+ char *fname = (char *)DatumGetPointer(filename);
+ if( fname != NULL )
+ {
+ if( unlink(fname) != 0 )
+ {
+ /* Should we complain if the unlink fails? */
+ }
+ free(fname);
+ }
}
/*