Re: [HACKERS] 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.

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(at)candle(dot)pha(dot)pa(dot)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)