Thread

1. Everything leaks; How it mm suppose to work?

   Maurice Gittens <mgittens@david.gits.nl> — 1998-04-02T13:40:57Z

   Hi,
   
   I added these lines to tcop/postgres.c just before the ReadCommand call
   (which is in an infinite loop).
   
   + 		printf("Allocount: %ld; FreeCount: %ld; Diff:%ld\n", 
   + 				getPAllocCount(),
   + 				getPFreeCount(),
   + 				getPAllocCount() - getPFreeCount());
   + 
   
   And the following lines to mmgr/palloc.c
     
   + static long pallocCount = 0;
   + static long pfreeCount = 0;
   + 
   + long getPAllocCount()
   + {
   + 	return pallocCount;
   + }
   + 
   + long getPFreeCount()
   + {
   + 	return pfreeCount;
   + }
   
     void *
     palloc(Size size)
     {
   + 	pallocCount++;
      ...
   
     void
     pfree(void *pointer)
     {
   + 	pfreeCount++;
           ...
   
   Running postgresql in interactive mode shows that for each query I 
   type there is memory lost. The exact amount of memory lost depends on
   the query I use. The amount of memory not freed is also a function
   of the number of tuples returned.
   
   Now I'm hoping there is an easy way to find out about how this is _supposed_ 
   to work. Any one feel like giving a nice little explanation?
   
   Thanks, with regards from Maurice.
    
   
   

2. Re: [HACKERS] Everything leaks; How it mm suppose to work?

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-04-02T15:58:08Z

   > 
   > Hi,
   > 
   > I added these lines to tcop/postgres.c just before the ReadCommand call
   > (which is in an infinite loop).
   > 
   > + 		printf("Allocount: %ld; FreeCount: %ld; Diff:%ld\n", 
   > + 				getPAllocCount(),
   > + 				getPFreeCount(),
   > + 				getPAllocCount() - getPFreeCount());
   > + 
   > 
   > And the following lines to mmgr/palloc.c
   >   
   > + static long pallocCount = 0;
   > + static long pfreeCount = 0;
   > + 
   > + long getPAllocCount()
   > + {
   > + 	return pallocCount;
   > + }
   > + 
   > + long getPFreeCount()
   > + {
   > + 	return pfreeCount;
   > + }
   > 
   >   void *
   >   palloc(Size size)
   >   {
   > + 	pallocCount++;
   >    ...
   > 
   >   void
   >   pfree(void *pointer)
   >   {
   > + 	pfreeCount++;
   >         ...
   > 
   > Running postgresql in interactive mode shows that for each query I 
   > type there is memory lost. The exact amount of memory lost depends on
   > the query I use. The amount of memory not freed is also a function
   > of the number of tuples returned.
   > 
   > Now I'm hoping there is an easy way to find out about how this is _supposed_ 
   > to work. Any one feel like giving a nice little explanation?
   > 
   > Thanks, with regards from Maurice.
   
   The way I was looking at it was to first find the context that is
   loosing the memory.  I called AllocSetDump(GlobalMemory->setData) to
   dump out the allocated memory pointers.  The problem is that only
   certain ones are do-able, as portals each have their own context, I
   think, and there is no macro that enables all the memory debugging
   operations.
   
   Not sure how to proceed.
   
   -- 
   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)
   
   

3. Re: [HACKERS] Everything leaks; How it mm suppose to work?

   David Gould <dg@illustra.com> — 1998-04-03T06:24:42Z

   > Hi,
   > 
   > I added these lines to tcop/postgres.c just before the ReadCommand call
   > (which is in an infinite loop).
   > 
   > + 		printf("Allocount: %ld; FreeCount: %ld; Diff:%ld\n", 
   > + 				getPAllocCount(),
   > + 				getPFreeCount(),
   > + 				getPAllocCount() - getPFreeCount());
   > + 
   > 
   > And the following lines to mmgr/palloc.c
   >   
   > + static long pallocCount = 0;
   > + static long pfreeCount = 0;
   > + 
   > + long getPAllocCount()
   > + {
   > + 	return pallocCount;
   > + }
   > + 
   > + long getPFreeCount()
   > + {
   > + 	return pfreeCount;
   > + }
   > 
   >   void *
   >   palloc(Size size)
   >   {
   > + 	pallocCount++;
   >    ...
   > 
   >   void
   >   pfree(void *pointer)
   >   {
   > + 	pfreeCount++;
   >         ...
   > 
   > Running postgresql in interactive mode shows that for each query I 
   > type there is memory lost. The exact amount of memory lost depends on
   > the query I use. The amount of memory not freed is also a function
   > of the number of tuples returned.
   > 
   > Now I'm hoping there is an easy way to find out about how this is _supposed_ 
   > to work. Any one feel like giving a nice little explanation?
   > 
   > Thanks, with regards from Maurice.
   >  
   
   The term "getPAllocCount() - getPFreeCount())" returns the amount of
   memory not explicitly freed. The rest of the memory was (probably) released
   by MemoryContextDestroy() when the context went out of scope.
   
   This is normal behavior under the current scheme.
   
   -dg
   
   David Gould            dg@illustra.com           510.628.3783 or 510.305.9468 
   Informix Software  (No, really)         300 Lakeside Drive  Oakland, CA 94612
   If simplicity worked, the world would be overrun with insects.
   
   

4. Problem with 6.3.1 under Linux RH5.0

   Edwin Ramirez <ramirez@doc.mssm.edu> — 1998-04-03T14:42:03Z

   Hello,
   
   I recall reading about a problem with subselects taking a long time to
   return.  I am experiencing similar problems under 6.3.1 running on Linux
   RedHat5.0.  The tables only contains approx 2k records and the command
   ran for about 10 minutes.
   
   Thanks,
   
   Edwin Ramirez