Guys, attached is a patch to fix two memory leaks on start-up. The
first is when freeaddrinfo has been used to free memory allocated by
getaddrinfo2 (so freeaddrinfo2 should be used). The second is 2 leaks
when creating the lock (PostgreSQL and socket) files.

The diff is against last night's CVS HEAD.

L.
Tue, 22 Jul 2003 09:14:21 +0100
Lee Kindness <lkindness@csl.co.uk>
PATCH: Memory leaks on start-up
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.

			regards, tom lane

Tue, 22 Jul 2003 09:58:38 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: PATCH: Memory leaks on start-up 
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.


Index: src/backend/libpq/pqcomm.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/backend/libpq/pqcomm.c,v
retrieving revision 1.157
diff -u -r1.157 pqcomm.c
--- src/backend/libpq/pqcomm.c	12 Jun 2003 07:36:51 -0000	1.157
+++ src/backend/libpq/pqcomm.c	22 Jul 2003 14:16:46 -0000
@@ -363,7 +363,7 @@
 		added++;
 	}
 
-	freeaddrinfo(addrs);
+	freeaddrinfo2(family, addrs);
 
 	if (!added)
 	{
Index: src/backend/utils/init/miscinit.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/backend/utils/init/miscinit.c,v
retrieving revision 1.104
diff -u -r1.104 miscinit.c
--- src/backend/utils/init/miscinit.c	27 Jun 2003 19:08:37 -0000	1.104
+++ src/backend/utils/init/miscinit.c	22 Jul 2003 14:16:46 -0000
@@ -673,8 +673,15 @@
 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);
+    }
 }
 
 /*
Tue, 22 Jul 2003 15:26:55 +0100
Lee Kindness <lkindness@csl.co.uk>
Re: PATCH: Memory leaks on start-up 
Lee Kindness <lkindness@csl.co.uk> writes:
> 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.

I don't see how.  We are talking about two strings, no more, no less,
that live for exactly the duration of the postmaster run.  Explain to me
how any of your above conditions will affect this code in the slightest?

If UnlinkLockFile ever got invoked before postmaster exit, then this
would be worth doing, and I'll accept the change as a matter of
future-proofing that routine against such use.  But on the argument of
preventing resource leakage today, this is just a waste of code space.

			regards, tom lane

Tue, 22 Jul 2003 10:39:38 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: PATCH: Memory leaks on start-up 
Tom Lane writes:
 > Lee Kindness <lkindness@csl.co.uk> writes:
 > > 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.
 > I don't see how.  We are talking about two strings, no more, no less,
 > that live for exactly the duration of the postmaster run.  Explain to me
 > how any of your above conditions will affect this code in the slightest?

For the lock file leak yeah - it's just 2 strings once in a blue
moon. However in the more general case of freeaddrinfo and the eniron
wizardry (which is also leaking, and is done every new instance,
yeah?) it does build up.

Anyway, it's no reason to be lazy/messy, is it?

L.

Tue, 22 Jul 2003 17:10:04 +0100
Lee Kindness <lkindness@csl.co.uk>
Re: [PATCHES] PATCH: Memory leaks on start-up 

Your patch has been added to the PostgreSQL unapplied patches list at:

	http://momjian.postgresql.org/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------


Lee Kindness wrote:
Content-Description: message body text

> 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.
> 

> Index: src/backend/libpq/pqcomm.c
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/backend/libpq/pqcomm.c,v
> retrieving revision 1.157
> diff -u -r1.157 pqcomm.c
> --- src/backend/libpq/pqcomm.c	12 Jun 2003 07:36:51 -0000	1.157
> +++ src/backend/libpq/pqcomm.c	22 Jul 2003 14:16:46 -0000
> @@ -363,7 +363,7 @@
>  		added++;
>  	}
>  
> -	freeaddrinfo(addrs);
> +	freeaddrinfo2(family, addrs);
>  
>  	if (!added)
>  	{
> Index: src/backend/utils/init/miscinit.c
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/backend/utils/init/miscinit.c,v
> retrieving revision 1.104
> diff -u -r1.104 miscinit.c
> --- src/backend/utils/init/miscinit.c	27 Jun 2003 19:08:37 -0000	1.104
> +++ src/backend/utils/init/miscinit.c	22 Jul 2003 14:16:46 -0000
> @@ -673,8 +673,15 @@
>  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);
> +    }
>  }
>  
>  /*

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

-- 
  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, Pennsylvania 19073

Thu, 24 Jul 2003 00:08:07 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] PATCH: Memory leaks on start-up

This patch no longer applies cleanly.  The call is now:

	    freeaddrinfo_all(hint.ai_family, addrs);

Would you please submit a new patch, or is it no longer required?  There
were two fixed in your patch.

Thanks.

---------------------------------------------------------------------------

Lee Kindness wrote:
Content-Description: message body text

> 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.
> 

> Index: src/backend/libpq/pqcomm.c
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/backend/libpq/pqcomm.c,v
> retrieving revision 1.157
> diff -u -r1.157 pqcomm.c
> --- src/backend/libpq/pqcomm.c	12 Jun 2003 07:36:51 -0000	1.157
> +++ src/backend/libpq/pqcomm.c	22 Jul 2003 14:16:46 -0000
> @@ -363,7 +363,7 @@
>  		added++;
>  	}
>  
> -	freeaddrinfo(addrs);
> +	freeaddrinfo2(family, addrs);
>  
>  	if (!added)
>  	{
> Index: src/backend/utils/init/miscinit.c
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/backend/utils/init/miscinit.c,v
> retrieving revision 1.104
> diff -u -r1.104 miscinit.c
> --- src/backend/utils/init/miscinit.c	27 Jun 2003 19:08:37 -0000	1.104
> +++ src/backend/utils/init/miscinit.c	22 Jul 2003 14:16:46 -0000
> @@ -673,8 +673,15 @@
>  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);
> +    }
>  }
>  
>  /*

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

-- 
  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, Pennsylvania 19073

Sun, 27 Jul 2003 01:45:05 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] PATCH: Memory leaks on start-up
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> This patch no longer applies cleanly.  The call is now:
> 	    freeaddrinfo_all(hint.ai_family, addrs);
> Would you please submit a new patch, or is it no longer required?

That part of the patch is not needed (it is the same as what I changed,
except that while I was at it I renamed freeaddrinfo2 to the hopefully
more mnemonic freeaddrinfo_all).  The change in miscinit should still
work though.

			regards, tom lane

Sun, 27 Jul 2003 11:40:57 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] PATCH: Memory leaks on start-up 

miscinit.c part of patch applied.  Thanks.

The other part Tom already addressed.

---------------------------------------------------------------------------



Lee Kindness wrote:
Content-Description: message body text

> 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.
> 

> Index: src/backend/libpq/pqcomm.c
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/backend/libpq/pqcomm.c,v
> retrieving revision 1.157
> diff -u -r1.157 pqcomm.c
> --- src/backend/libpq/pqcomm.c	12 Jun 2003 07:36:51 -0000	1.157
> +++ src/backend/libpq/pqcomm.c	22 Jul 2003 14:16:46 -0000
> @@ -363,7 +363,7 @@
>  		added++;
>  	}
>  
> -	freeaddrinfo(addrs);
> +	freeaddrinfo2(family, addrs);
>  
>  	if (!added)
>  	{
> Index: src/backend/utils/init/miscinit.c
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/backend/utils/init/miscinit.c,v
> retrieving revision 1.104
> diff -u -r1.104 miscinit.c
> --- src/backend/utils/init/miscinit.c	27 Jun 2003 19:08:37 -0000	1.104
> +++ src/backend/utils/init/miscinit.c	22 Jul 2003 14:16:46 -0000
> @@ -673,8 +673,15 @@
>  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);
> +    }
>  }
>  
>  /*

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

-- 
  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, Pennsylvania 19073

Sun, 27 Jul 2003 15:39:34 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] PATCH: Memory leaks on start-up