Bruce Momjian wrote:
> 
> > I seem to recall a discussion a long time ago about using strdup and how
> > it would leak when using the postgres memory contexts, and that the pstrdup
> > code was created to be used instead of strdup to "fix" this.
> >
> 
> OK, here is a patch to fix the memory leak problem.  Not sure when this
> was introduced, but who cares.  Probably not Vadim, as I first thought.

(Sure - not me :). Congratulations with finding this!
storage/buffer/bufmgr.c:BufferAlloc():

    strcpy(buf->sb_dbname, GetDatabaseName());

and so we had leak for _every_ new buffer allocation!

But why strdup() was added there? (Hope that nothing is broken now).

Vadim

Sun, 05 Apr 1998 21:54:57 +0800
"Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>
Re: [PATCHES] Re: [HACKERS] Everything leaks;
	How it mm suppose to work?
> 
> Bruce Momjian wrote:
> > 
> > > I seem to recall a discussion a long time ago about using strdup and how
> > > it would leak when using the postgres memory contexts, and that the pstrdup
> > > code was created to be used instead of strdup to "fix" this.
> > >
> > 
> > OK, here is a patch to fix the memory leak problem.  Not sure when this
> > was introduced, but who cares.  Probably not Vadim, as I first thought.
> 
> (Sure - not me :). Congratulations with finding this!
> storage/buffer/bufmgr.c:BufferAlloc():
> 
>     strcpy(buf->sb_dbname, GetDatabaseName());
> 
> and so we had leak for _every_ new buffer allocation!
> 
> But why strdup() was added there? (Hope that nothing is broken now).

No idea, but it was not needed.  Removed the strdup, changed the
function to return a const char, and everything worked, so nothing was
changing the value.  (pstrdup() did not work because the allocation was
probably being done in the CacheCxt).  Also checked each call, and no
one was changing the variable, so no need for the strdup().

In fact, I am going to remove the Get/Set functions entirely(too many
calls), make it a global variable, and add to the TODO list:

	for safety, make global variables const, cast to non-const as needed

This will be a more general solution for global variable protection.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Sun, 5 Apr 1998 10:28:25 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [PATCHES] Re: [HACKERS] Everything leaks;
	How it mm suppose to work?