Tom, happier with the attached patch?

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

src/backend/utils/init/miscinit.c

@@ -8,7 +8,7 @@
  *
  *
  * 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 $
  *
  *-------------------------------------------------------------------------
  */
@@ -685,8 +685,15 @@ GetUserNameFromId(AclId userid)
 static void
 UnlinkLockFile(int status, Datum filename)
 {
-	unlink((char *) DatumGetPointer(filename));
+  char *fname = (char *)DatumGetPointer(filename);
+  if( fname != NULL )
+    {
+      if( unlink(fname) != 0 )
+	{
 	  /* Should we complain if the unlink fails? */
+	}
+      free(fname);
+    }
 }
 
 /*