Thread: Everything leaks; How it mm suppose to work?

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.

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

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

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